RE: [PATCH 2/2] drm/amd/powerplay: enable df cstate control on swSMU routine

[Zhang, Hawking]

Yes, we have to toggle DF-C state before/after programming DF Perf counter 
registers. The series is to provide interface for such case.

Regards,
Hawking

-Original Message-
From: amd-gfx  On Behalf Of Feng, Kenneth
Sent: 2019年10月10日 12:50
To: Quan, Evan ; amd-gfx@lists.freedesktop.org
Cc: Quan, Evan 
Subject: RE: [PATCH 2/2] drm/amd/powerplay: enable df cstate control on swSMU 
routine

Hi Evan,
Is there any use case for this interface?
Thanks.

-Original Message-
From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Quan, 
Evan
Sent: Thursday, October 10, 2019 11:45 AM
To: amd-gfx@lists.freedesktop.org
Cc: Quan, Evan 
Subject: [PATCH 2/2] drm/amd/powerplay: enable df cstate control on swSMU 
routine

[CAUTION: External Email]

Currently this is only supported on Vega20 with 40.50 and later SMC firmware.

Change-Id: I8397f9ccc5dec32dc86ef7635c5ed227c77e61a3
Signed-off-by: Evan Quan 
---
 drivers/gpu/drm/amd/powerplay/amdgpu_smu.c| 23 +
 .../gpu/drm/amd/powerplay/inc/amdgpu_smu.h|  3 +++
 drivers/gpu/drm/amd/powerplay/inc/smu_types.h |  1 +
 drivers/gpu/drm/amd/powerplay/vega20_ppt.c| 25 ++-
 4 files changed, 51 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c 
b/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c
index 054376342454..a37a1b1d8abd 100644
--- a/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c
+++ b/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c
@@ -1834,6 +1834,29 @@ int smu_set_mp1_state(struct smu_context *smu,
return ret;
 }

+int smu_set_df_cstate(struct smu_context *smu,
+ enum pp_df_cstate state) {
+   int ret = 0;
+
+   /*
+* The SMC is not fully ready. That may be
+* expected as the IP may be masked.
+* So, just return without error.
+*/
+   if (!smu->pm_enabled)
+   return 0;
+
+   if (!smu->ppt_funcs || !smu->ppt_funcs->set_df_cstate)
+   return 0;
+
+   ret = smu->ppt_funcs->set_df_cstate(smu, state);
+   if (ret)
+   pr_err("[SetDfCstate] failed!\n");
+
+   return ret;
+}
+
 const struct amd_ip_funcs smu_ip_funcs = {
.name = "smu",
.early_init = smu_early_init,
diff --git a/drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h 
b/drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h
index ccf711c327c8..401affdee49d 100644
--- a/drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h
+++ b/drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h
@@ -468,6 +468,7 @@ struct pptable_funcs {
int (*get_power_limit)(struct smu_context *smu, uint32_t *limit, bool 
asic_default);
int (*get_dpm_clk_limited)(struct smu_context *smu, enum smu_clk_type 
clk_type,
   uint32_t dpm_level, uint32_t *freq);
+   int (*set_df_cstate)(struct smu_context *smu, enum pp_df_cstate 
+ state);
 };

 struct smu_funcs
@@ -852,5 +853,7 @@ int smu_force_clk_levels(struct smu_context *smu,
 uint32_t mask);  int smu_set_mp1_state(struct 
smu_context *smu,
  enum pp_mp1_state mp1_state);
+int smu_set_df_cstate(struct smu_context *smu,
+ enum pp_df_cstate state);

 #endif
diff --git a/drivers/gpu/drm/amd/powerplay/inc/smu_types.h 
b/drivers/gpu/drm/amd/powerplay/inc/smu_types.h
index 12a1de55ce3c..d8c9b7f91fcc 100644
--- a/drivers/gpu/drm/amd/powerplay/inc/smu_types.h
+++ b/drivers/gpu/drm/amd/powerplay/inc/smu_types.h
@@ -169,6 +169,7 @@
__SMU_DUMMY_MAP(PowerGateAtHub),  \
__SMU_DUMMY_MAP(SetSoftMinJpeg),  \
__SMU_DUMMY_MAP(SetHardMinFclkByFreq),\
+   __SMU_DUMMY_MAP(DFCstateControl), \

 #undef __SMU_DUMMY_MAP
 #define __SMU_DUMMY_MAP(type)  SMU_MSG_##type diff --git 
a/drivers/gpu/drm/amd/powerplay/vega20_ppt.c 
b/drivers/gpu/drm/amd/powerplay/vega20_ppt.c
index 99effde33ac1..1050566cb69a 100644
--- a/drivers/gpu/drm/amd/powerplay/vega20_ppt.c
+++ b/drivers/gpu/drm/amd/powerplay/vega20_ppt.c
@@ -143,6 +143,7 @@ static struct smu_11_0_cmn2aisc_mapping 
vega20_message_map[SMU_MSG_MAX_COUNT] =
MSG_MAP(PrepareMp1ForShutdown),
MSG_MAP(SetMGpuFanBoostLimitRpm),
MSG_MAP(GetAVFSVoltageByDpm),
+   MSG_MAP(DFCstateControl),
 };

 static struct smu_11_0_cmn2aisc_mapping vega20_clk_map[SMU_CLK_COUNT] = { @@ 
-3135,6 +3136,27 @@ static int vega20_get_thermal_temperature_range(struct 
smu_context *smu,
return 0;
 }

+static int vega20_set_df_cstate(struct smu_context *smu,
+   enum pp_df_cstate state) {
+   uint32_t smu_version;
+   int ret;
+
+   ret = smu_get_smc_version(smu, NULL, _version);
+   if (ret) {
+   pr_err("Failed to get smu version!\n");
+   return ret;
+   }
+
+   /* PPSMC_MSG_DFCstateControl is supported with 40.50 and later fws */
+   if (smu_version < 0x283200) {
+   pr_err("Df cstate control is supported 

Potential NULL pointer deference in drm/amdgpu

[Yizhuo Zhai]

Hi All:
drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c:
The function to_amdgpu_fence() could return NULL, but callers
in this file does not check the return value but directly dereference it,
which seems potentially unsafe.
Such callers include amdgpu_fence_get_timeline_name(),
amdgpu_fence_enable_signaling() and amdgpu_fence_free().


-- 
Kind Regards,

Yizhuo Zhai

Computer Science, Graduate Student
University of California, Riverside

RE: [PATCH 2/2] drm/amd/powerplay: enable df cstate control on swSMU routine

[Feng, Kenneth]

Hi Evan,
Is there any use case for this interface?
Thanks.

-Original Message-
From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Quan, 
Evan
Sent: Thursday, October 10, 2019 11:45 AM
To: amd-gfx@lists.freedesktop.org
Cc: Quan, Evan 
Subject: [PATCH 2/2] drm/amd/powerplay: enable df cstate control on swSMU 
routine

[CAUTION: External Email]

Currently this is only supported on Vega20 with 40.50 and later SMC firmware.

Change-Id: I8397f9ccc5dec32dc86ef7635c5ed227c77e61a3
Signed-off-by: Evan Quan 
---
 drivers/gpu/drm/amd/powerplay/amdgpu_smu.c| 23 +
 .../gpu/drm/amd/powerplay/inc/amdgpu_smu.h|  3 +++
 drivers/gpu/drm/amd/powerplay/inc/smu_types.h |  1 +
 drivers/gpu/drm/amd/powerplay/vega20_ppt.c| 25 ++-
 4 files changed, 51 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c 
b/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c
index 054376342454..a37a1b1d8abd 100644
--- a/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c
+++ b/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c
@@ -1834,6 +1834,29 @@ int smu_set_mp1_state(struct smu_context *smu,
return ret;
 }

+int smu_set_df_cstate(struct smu_context *smu,
+ enum pp_df_cstate state) {
+   int ret = 0;
+
+   /*
+* The SMC is not fully ready. That may be
+* expected as the IP may be masked.
+* So, just return without error.
+*/
+   if (!smu->pm_enabled)
+   return 0;
+
+   if (!smu->ppt_funcs || !smu->ppt_funcs->set_df_cstate)
+   return 0;
+
+   ret = smu->ppt_funcs->set_df_cstate(smu, state);
+   if (ret)
+   pr_err("[SetDfCstate] failed!\n");
+
+   return ret;
+}
+
 const struct amd_ip_funcs smu_ip_funcs = {
.name = "smu",
.early_init = smu_early_init,
diff --git a/drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h 
b/drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h
index ccf711c327c8..401affdee49d 100644
--- a/drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h
+++ b/drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h
@@ -468,6 +468,7 @@ struct pptable_funcs {
int (*get_power_limit)(struct smu_context *smu, uint32_t *limit, bool 
asic_default);
int (*get_dpm_clk_limited)(struct smu_context *smu, enum smu_clk_type 
clk_type,
   uint32_t dpm_level, uint32_t *freq);
+   int (*set_df_cstate)(struct smu_context *smu, enum pp_df_cstate 
+ state);
 };

 struct smu_funcs
@@ -852,5 +853,7 @@ int smu_force_clk_levels(struct smu_context *smu,
 uint32_t mask);  int smu_set_mp1_state(struct 
smu_context *smu,
  enum pp_mp1_state mp1_state);
+int smu_set_df_cstate(struct smu_context *smu,
+ enum pp_df_cstate state);

 #endif
diff --git a/drivers/gpu/drm/amd/powerplay/inc/smu_types.h 
b/drivers/gpu/drm/amd/powerplay/inc/smu_types.h
index 12a1de55ce3c..d8c9b7f91fcc 100644
--- a/drivers/gpu/drm/amd/powerplay/inc/smu_types.h
+++ b/drivers/gpu/drm/amd/powerplay/inc/smu_types.h
@@ -169,6 +169,7 @@
__SMU_DUMMY_MAP(PowerGateAtHub),  \
__SMU_DUMMY_MAP(SetSoftMinJpeg),  \
__SMU_DUMMY_MAP(SetHardMinFclkByFreq),\
+   __SMU_DUMMY_MAP(DFCstateControl), \

 #undef __SMU_DUMMY_MAP
 #define __SMU_DUMMY_MAP(type)  SMU_MSG_##type diff --git 
a/drivers/gpu/drm/amd/powerplay/vega20_ppt.c 
b/drivers/gpu/drm/amd/powerplay/vega20_ppt.c
index 99effde33ac1..1050566cb69a 100644
--- a/drivers/gpu/drm/amd/powerplay/vega20_ppt.c
+++ b/drivers/gpu/drm/amd/powerplay/vega20_ppt.c
@@ -143,6 +143,7 @@ static struct smu_11_0_cmn2aisc_mapping 
vega20_message_map[SMU_MSG_MAX_COUNT] =
MSG_MAP(PrepareMp1ForShutdown),
MSG_MAP(SetMGpuFanBoostLimitRpm),
MSG_MAP(GetAVFSVoltageByDpm),
+   MSG_MAP(DFCstateControl),
 };

 static struct smu_11_0_cmn2aisc_mapping vega20_clk_map[SMU_CLK_COUNT] = { @@ 
-3135,6 +3136,27 @@ static int vega20_get_thermal_temperature_range(struct 
smu_context *smu,
return 0;
 }

+static int vega20_set_df_cstate(struct smu_context *smu,
+   enum pp_df_cstate state) {
+   uint32_t smu_version;
+   int ret;
+
+   ret = smu_get_smc_version(smu, NULL, _version);
+   if (ret) {
+   pr_err("Failed to get smu version!\n");
+   return ret;
+   }
+
+   /* PPSMC_MSG_DFCstateControl is supported with 40.50 and later fws */
+   if (smu_version < 0x283200) {
+   pr_err("Df cstate control is supported with 40.50 and later SMC 
fw!\n");
+   return -EINVAL;
+   }
+
+   return smu_send_smc_msg_with_param(smu, SMU_MSG_DFCstateControl, 
+state); }
+
 static const struct pptable_funcs vega20_ppt_funcs = {
.tables_init = vega20_tables_init,
.alloc_dpm_context = vega20_allocate_dpm_context, @@ -3177,7 +3199,8 @@ 
static const struct pptable_funcs vega20_ppt_funcs = 

[pull] amdgpu/kfd, radeon, ttm drm-next-5.5

[Alex Deucher]

Hi Dave, Daniel,

New stuff for 5.5.  There's an export of a cgroup function that
Tejun acked for merging through the drm tree. kfd uses it to handle
permissions in containers since there is only one /dev/kfd.

The following changes since commit 9a60b2990d6c2b7ab935fe0a5cc274de67d98bed:

  Merge branch 'etnaviv/next' of https://git.pengutronix.de/git/lst/linux into 
drm-next (2019-09-06 16:58:10 +1000)

are available in the Git repository at:

  git://people.freedesktop.org/~agd5f/linux tags/drm-next-5.5-2019-10-09

for you to fetch changes up to 1cd4d9eead73c004d08a58536dc726bd172eaaec:

  drm/amdkfd: update for drmP.h removal (2019-10-09 12:04:48 -0500)


drm-next-5.5-2019-10-09:

amdgpu:
- Additional RAS enablement for vega20
- RAS page retirement and bad page storage in EEPROM
- No GPU reset with unrecoverable RAS errors
- Reserve vram for page tables rather than trying to evict
- Fix issues with GPU reset and xgmi hives
- DC i2c over aux fixes
- Direct submission for clears, PTE/PDE updates
- Improvements to help support recoverable GPU page faults
- Silence harmless SAD block messages
- Clean up code for creating a bo at a fixed location
- Initial DC HDCP support
- Lots of documentation fixes
- GPU reset for renoir
- Add IH clockgating support for soc15 asics
- Powerplay improvements
- DC MST cleanups
- Add support for MSI-X
- Misc cleanups and bug fixes

amdkfd:
- Query KFD device info by asic type rather than pci ids
- Add navi14 support
- Add renoir support
- Add navi12 support
- gfx10 trap handler improvements
- pasid cleanups
- Check against device cgroup

ttm:
- Return -EBUSY with pipelining with no_gpu_wait

radeon:
- Silence harmless SAD block messages

device_cgroup:
- Export devcgroup_check_permission


Aaron Liu (4):
  drm/amd/display: update renoir_ip_offset.h
  drm/amdgpu: disable stutter mode for renoir
  drm/amdgpu: remove program of lbpw for renoir
  Revert "drm/amdgpu: disable stutter mode for renoir"

Adam Zerella (1):
  docs: drm/amdgpu: Resolve build warnings

Alex Deucher (20):
  drm/amdgpu/irq: check if nbio funcs exist
  drm/amdgpu/vm: fix documentation for amdgpu_vm_bo_param
  drm/amdgpu/ras: use GPU PAGE_SIZE/SHIFT for reserving pages
  drm/amdgpu/psp: flush HDP write fifo after submitting cmds to the psp
  drm/amdgpu/psp: invalidate the hdp read cache before reading the psp 
response
  drm/amdgpu: flag navi12 and 14 as experimental for 5.4
  drm/amdgpu: fix documentation for amdgpu_gem_prime_export
  drm/amdgpu/mn: fix documentation for amdgpu_mn_read_lock
  drm/amdgpu/vm: fix up documentation in amdgpu_vm.c
  drm/amdgpu/ih: fix documentation in amdgpu_irq_dispatch
  drm/amdgpu: fix documentation for amdgpu_pm.c
  drm/amdgpu/ras: fix and update the documentation for RAS
  drm/amdgpu/display: fix 64 bit divide
  drm/amdgpu/display: include slab.h in dcn21_resource.c
  drm/amdgpu/atomfirmware: use proper index for querying vram type (v3)
  drm/amdgpu/atomfirmware: simplify the interface to get vram info
  drm/amdgpu: don't increment vram lost if we are in hibernation
  drm/amdgpu: improve MSI-X handling (v3)
  drm/amdgpu: move amdgpu_device_get_job_timeout_settings
  drm/amdkfd: fix the build when CIK support is disabled

Allen Pais (1):
  drm/amdkfd: fix a potential NULL pointer dereference (v2)

Alvin Lee (1):
  drm/amd/display: Don't allocate payloads if link lost

Andrey Grodzovsky (11):
  drm/amdgpu: Fix bugs in amdgpu_device_gpu_recover in XGMI case.
  drm/amdgpu: Avoid HW GPU reset for RAS.
  dmr/amdgpu: Add system auto reboot to RAS.
  drm/amdgpu: Add smu lock around in pp_smu_i2c_bus_access
  drm/amdgpu: Remove clock gating restore.
  drm/madgpu: Fix EEPROM Checksum calculation.
  drm/amdgpu: Avoid RAS recovery init when no RAS support.
  drm/amdgpu: Add amdgpu_ras_eeprom_reset_table
  drm/amdgpu: Allow to reset to EERPOM table.
  drm/amdgpu: Fix mutex lock from atomic context.
  drm/amdgpu:Fix EEPROM checksum calculation.

Anthony Koo (2):
  drm/amd/display: 3.2.49
  drm/amd/display: set minimum abm backlight level

Aric Cyr (4):
  drm/amd/display: 3.2.50
  drm/amd/display: 3.2.51
  drm/amd/display: 3.2.51.1
  drm/amd/display: Improve LFC behaviour

Arnd Bergmann (4):
  drm/amd/display: hide an unused variable
  drm/amdgpu: make pmu support optional, again
  drm/amdgpu: hide another #warning
  drm/amdgpu: display_mode_vba_21: remove uint typedef

Austin Kim (1):
  drm/amdgpu: Drop unused variable and statement

Bayan Zabihiyan (1):
  drm/amd/display: Isolate DSC module from driver dependencies

Bhawanpreet Lakha (15):
  drm/amd/display: add Asic ID for Dali
  drm/amd/display: Implement voltage limitation for dali
  drm/amdgpu: psp 

[PATCH 1/2] drm/amd/powerplay: enable df cstate control on powerplay routine

[Quan, Evan]

Currently this is only supported on Vega20 with 40.50 and later
SMC firmware.

Change-Id: I4f2f7936a3bc6e1a32d590bc76ebfc9a5a53f9cb
Signed-off-by: Evan Quan 
---
 .../gpu/drm/amd/include/kgd_pp_interface.h|  6 ++
 drivers/gpu/drm/amd/powerplay/amd_powerplay.c | 18 ++
 .../drm/amd/powerplay/hwmgr/vega20_hwmgr.c| 19 +++
 drivers/gpu/drm/amd/powerplay/inc/hwmgr.h |  1 +
 .../gpu/drm/amd/powerplay/inc/vega20_ppsmc.h  |  3 ++-
 5 files changed, 46 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/include/kgd_pp_interface.h 
b/drivers/gpu/drm/amd/include/kgd_pp_interface.h
index 27cf0afaa0b4..5902f80d1fce 100644
--- a/drivers/gpu/drm/amd/include/kgd_pp_interface.h
+++ b/drivers/gpu/drm/amd/include/kgd_pp_interface.h
@@ -179,6 +179,11 @@ enum pp_mp1_state {
PP_MP1_STATE_RESET,
 };
 
+enum pp_df_cstate {
+   DF_CSTATE_DISALLOW = 0,
+   DF_CSTATE_ALLOW,
+};
+
 #define PP_GROUP_MASK0xF000
 #define PP_GROUP_SHIFT   28
 
@@ -312,6 +317,7 @@ struct amd_pm_funcs {
int (*get_ppfeature_status)(void *handle, char *buf);
int (*set_ppfeature_status)(void *handle, uint64_t ppfeature_masks);
int (*asic_reset_mode_2)(void *handle);
+   int (*set_df_cstate)(void *handle, enum pp_df_cstate state);
 };
 
 #endif
diff --git a/drivers/gpu/drm/amd/powerplay/amd_powerplay.c 
b/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
index fa8ad7db2b3a..83196b79edd5 100644
--- a/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
+++ b/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
@@ -1548,6 +1548,23 @@ static int pp_smu_i2c_bus_access(void *handle, bool 
acquire)
return ret;
 }
 
+static int pp_set_df_cstate(void *handle, enum pp_df_cstate state)
+{
+   struct pp_hwmgr *hwmgr = handle;
+
+   if (!hwmgr)
+   return -EINVAL;
+
+   if (!hwmgr->pm_en || !hwmgr->hwmgr_func->set_df_cstate)
+   return 0;
+
+   mutex_lock(>smu_lock);
+   hwmgr->hwmgr_func->set_df_cstate(hwmgr, state);
+   mutex_unlock(>smu_lock);
+
+   return 0;
+}
+
 static const struct amd_pm_funcs pp_dpm_funcs = {
.load_firmware = pp_dpm_load_fw,
.wait_for_fw_loading_complete = pp_dpm_fw_loading_complete,
@@ -1606,4 +1623,5 @@ static const struct amd_pm_funcs pp_dpm_funcs = {
.set_ppfeature_status = pp_set_ppfeature_status,
.asic_reset_mode_2 = pp_asic_reset_mode_2,
.smu_i2c_bus_access = pp_smu_i2c_bus_access,
+   .set_df_cstate = pp_set_df_cstate,
 };
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c
index f5915308e643..6629c475fe5d 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c
@@ -4155,6 +4155,24 @@ static int vega20_smu_i2c_bus_access(struct pp_hwmgr 
*hwmgr, bool acquire)
return res;
 }
 
+static int vega20_set_df_cstate(struct pp_hwmgr *hwmgr,
+   enum pp_df_cstate state)
+{
+   int ret;
+
+   /* PPSMC_MSG_DFCstateControl is supported with 40.50 and later fws */
+   if (hwmgr->smu_version < 0x283200) {
+   pr_err("Df cstate control is supported with 40.50 and later SMC 
fw!\n");
+   return -EINVAL;
+   }
+
+   ret = smum_send_msg_to_smc_with_parameter(hwmgr, 
PPSMC_MSG_DFCstateControl, state);
+   if (ret)
+   pr_err("SetDfCstate failed!\n");
+
+   return ret;
+}
+
 static const struct pp_hwmgr_func vega20_hwmgr_funcs = {
/* init/fini related */
.backend_init = vega20_hwmgr_backend_init,
@@ -4223,6 +4241,7 @@ static const struct pp_hwmgr_func vega20_hwmgr_funcs = {
.set_asic_baco_state = vega20_baco_set_state,
.set_mp1_state = vega20_set_mp1_state,
.smu_i2c_bus_access = vega20_smu_i2c_bus_access,
+   .set_df_cstate = vega20_set_df_cstate,
 };
 
 int vega20_hwmgr_init(struct pp_hwmgr *hwmgr)
diff --git a/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h 
b/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h
index 7bf9a14bfa0b..bd8c922dfd3e 100644
--- a/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h
+++ b/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h
@@ -355,6 +355,7 @@ struct pp_hwmgr_func {
int (*set_mp1_state)(struct pp_hwmgr *hwmgr, enum pp_mp1_state 
mp1_state);
int (*asic_reset)(struct pp_hwmgr *hwmgr, enum SMU_ASIC_RESET_MODE 
mode);
int (*smu_i2c_bus_access)(struct pp_hwmgr *hwmgr, bool aquire);
+   int (*set_df_cstate)(struct pp_hwmgr *hwmgr, enum pp_df_cstate state);
 };
 
 struct pp_table_func {
diff --git a/drivers/gpu/drm/amd/powerplay/inc/vega20_ppsmc.h 
b/drivers/gpu/drm/amd/powerplay/inc/vega20_ppsmc.h
index a0883038f3c3..0c66f0fe1aaf 100644
--- a/drivers/gpu/drm/amd/powerplay/inc/vega20_ppsmc.h
+++ b/drivers/gpu/drm/amd/powerplay/inc/vega20_ppsmc.h
@@ -120,7 +120,8 @@
 #define PPSMC_MSG_SetMGpuFanBoostLimitRpm0x5D
 #define PPSMC_MSG_GetAVFSVoltageByDpm   

[PATCH 2/2] drm/amd/powerplay: enable df cstate control on swSMU routine

[Quan, Evan]

Currently this is only supported on Vega20 with 40.50 and later
SMC firmware.

Change-Id: I8397f9ccc5dec32dc86ef7635c5ed227c77e61a3
Signed-off-by: Evan Quan 
---
 drivers/gpu/drm/amd/powerplay/amdgpu_smu.c| 23 +
 .../gpu/drm/amd/powerplay/inc/amdgpu_smu.h|  3 +++
 drivers/gpu/drm/amd/powerplay/inc/smu_types.h |  1 +
 drivers/gpu/drm/amd/powerplay/vega20_ppt.c| 25 ++-
 4 files changed, 51 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c 
b/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c
index 054376342454..a37a1b1d8abd 100644
--- a/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c
+++ b/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c
@@ -1834,6 +1834,29 @@ int smu_set_mp1_state(struct smu_context *smu,
return ret;
 }
 
+int smu_set_df_cstate(struct smu_context *smu,
+ enum pp_df_cstate state)
+{
+   int ret = 0;
+
+   /*
+* The SMC is not fully ready. That may be
+* expected as the IP may be masked.
+* So, just return without error.
+*/
+   if (!smu->pm_enabled)
+   return 0;
+
+   if (!smu->ppt_funcs || !smu->ppt_funcs->set_df_cstate)
+   return 0;
+
+   ret = smu->ppt_funcs->set_df_cstate(smu, state);
+   if (ret)
+   pr_err("[SetDfCstate] failed!\n");
+
+   return ret;
+}
+
 const struct amd_ip_funcs smu_ip_funcs = {
.name = "smu",
.early_init = smu_early_init,
diff --git a/drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h 
b/drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h
index ccf711c327c8..401affdee49d 100644
--- a/drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h
+++ b/drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h
@@ -468,6 +468,7 @@ struct pptable_funcs {
int (*get_power_limit)(struct smu_context *smu, uint32_t *limit, bool 
asic_default);
int (*get_dpm_clk_limited)(struct smu_context *smu, enum smu_clk_type 
clk_type,
   uint32_t dpm_level, uint32_t *freq);
+   int (*set_df_cstate)(struct smu_context *smu, enum pp_df_cstate state);
 };
 
 struct smu_funcs
@@ -852,5 +853,7 @@ int smu_force_clk_levels(struct smu_context *smu,
 uint32_t mask);
 int smu_set_mp1_state(struct smu_context *smu,
  enum pp_mp1_state mp1_state);
+int smu_set_df_cstate(struct smu_context *smu,
+ enum pp_df_cstate state);
 
 #endif
diff --git a/drivers/gpu/drm/amd/powerplay/inc/smu_types.h 
b/drivers/gpu/drm/amd/powerplay/inc/smu_types.h
index 12a1de55ce3c..d8c9b7f91fcc 100644
--- a/drivers/gpu/drm/amd/powerplay/inc/smu_types.h
+++ b/drivers/gpu/drm/amd/powerplay/inc/smu_types.h
@@ -169,6 +169,7 @@
__SMU_DUMMY_MAP(PowerGateAtHub),  \
__SMU_DUMMY_MAP(SetSoftMinJpeg),  \
__SMU_DUMMY_MAP(SetHardMinFclkByFreq),\
+   __SMU_DUMMY_MAP(DFCstateControl), \
 
 #undef __SMU_DUMMY_MAP
 #define __SMU_DUMMY_MAP(type)  SMU_MSG_##type
diff --git a/drivers/gpu/drm/amd/powerplay/vega20_ppt.c 
b/drivers/gpu/drm/amd/powerplay/vega20_ppt.c
index 99effde33ac1..1050566cb69a 100644
--- a/drivers/gpu/drm/amd/powerplay/vega20_ppt.c
+++ b/drivers/gpu/drm/amd/powerplay/vega20_ppt.c
@@ -143,6 +143,7 @@ static struct smu_11_0_cmn2aisc_mapping 
vega20_message_map[SMU_MSG_MAX_COUNT] =
MSG_MAP(PrepareMp1ForShutdown),
MSG_MAP(SetMGpuFanBoostLimitRpm),
MSG_MAP(GetAVFSVoltageByDpm),
+   MSG_MAP(DFCstateControl),
 };
 
 static struct smu_11_0_cmn2aisc_mapping vega20_clk_map[SMU_CLK_COUNT] = {
@@ -3135,6 +3136,27 @@ static int vega20_get_thermal_temperature_range(struct 
smu_context *smu,
return 0;
 }
 
+static int vega20_set_df_cstate(struct smu_context *smu,
+   enum pp_df_cstate state)
+{
+   uint32_t smu_version;
+   int ret;
+
+   ret = smu_get_smc_version(smu, NULL, _version);
+   if (ret) {
+   pr_err("Failed to get smu version!\n");
+   return ret;
+   }
+
+   /* PPSMC_MSG_DFCstateControl is supported with 40.50 and later fws */
+   if (smu_version < 0x283200) {
+   pr_err("Df cstate control is supported with 40.50 and later SMC 
fw!\n");
+   return -EINVAL;
+   }
+
+   return smu_send_smc_msg_with_param(smu, SMU_MSG_DFCstateControl, state);
+}
+
 static const struct pptable_funcs vega20_ppt_funcs = {
.tables_init = vega20_tables_init,
.alloc_dpm_context = vega20_allocate_dpm_context,
@@ -3177,7 +3199,8 @@ static const struct pptable_funcs vega20_ppt_funcs = {
.get_fan_speed_percent = vega20_get_fan_speed_percent,
.get_fan_speed_rpm = vega20_get_fan_speed_rpm,
.set_watermarks_table = vega20_set_watermarks_table,
-   .get_thermal_temperature_range = vega20_get_thermal_temperature_range
+   .get_thermal_temperature_range = vega20_get_thermal_temperature_range,
+   .set_df_cstate = 

[pull] amdgpu drm-fixes-5.4

[Alex Deucher]

Hi Dave, Daniel,

Just a single fix this week for 5.4.

The following changes since commit da0c9ea146cbe92b832f1b0f694840ea8eb33cce:

  Linux 5.4-rc2 (2019-10-06 14:27:30 -0700)

are available in the Git repository at:

  git://people.freedesktop.org/~agd5f/linux tags/drm-fixes-5.4-2019-10-09

for you to fetch changes up to 083164dbdb17c5ea4ad92c1782b59c9d75567790:

  drm/amdgpu: fix memory leak (2019-10-09 11:45:59 -0500)


drm-fixes-5.4-2019-10-09:

amdgpu:
- fix memory leak in bo_list ioctl error path


Nirmoy Das (1):
  drm/amdgpu: fix memory leak

 drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 1/2] drm/amd/powerplay: add more feature bits

[Wang, Kevin(Yang)]

Reviewed-by: Kevin Wang 

Best Regards,
Kevin


From: Alex Deucher 
Sent: Thursday, October 10, 2019 10:33 AM
To: Yuan, Xiaojie 
Cc: amd-gfx@lists.freedesktop.org ; Xiao, Jack 
; Quan, Evan ; Feng, Kenneth 
; Wang, Kevin(Yang) ; Zhang, Hawking 

Subject: Re: [PATCH 1/2] drm/amd/powerplay: add more feature bits

Acked-by: Alex Deucher 

On Wed, Oct 9, 2019 at 10:25 PM Yuan, Xiaojie  wrote:
>
> Ping ...
>
> BR,
> Xiaojie
> 
> From: Yuan, Xiaojie 
> Sent: Wednesday, October 9, 2019 7:08 PM
> To: amd-gfx@lists.freedesktop.org 
> Cc: Zhang, Hawking ; Xiao, Jack ; 
> Feng, Kenneth ; Quan, Evan ; Wang, 
> Kevin(Yang) ; Yuan, Xiaojie 
> Subject: [PATCH 1/2] drm/amd/powerplay: add more feature bits
>
> Signed-off-by: Xiaojie Yuan 
> ---
>  drivers/gpu/drm/amd/powerplay/navi10_ppt.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/navi10_ppt.c 
> b/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
> index 5a34d01f7f7c..44152c1f01c7 100644
> --- a/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
> +++ b/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
> @@ -337,19 +337,22 @@ navi10_get_allowed_feature_mask(struct smu_context *smu,
>  | FEATURE_MASK(FEATURE_PPT_BIT)
>  | FEATURE_MASK(FEATURE_TDC_BIT)
>  | FEATURE_MASK(FEATURE_GFX_EDC_BIT)
> +   | FEATURE_MASK(FEATURE_APCC_PLUS_BIT)
>  | FEATURE_MASK(FEATURE_VR0HOT_BIT)
>  | FEATURE_MASK(FEATURE_FAN_CONTROL_BIT)
>  | FEATURE_MASK(FEATURE_THERMAL_BIT)
>  | FEATURE_MASK(FEATURE_LED_DISPLAY_BIT)
>  | FEATURE_MASK(FEATURE_DPM_DCEFCLK_BIT)
>  | FEATURE_MASK(FEATURE_DS_GFXCLK_BIT)
> +   | FEATURE_MASK(FEATURE_DS_LCLK_BIT)
>  | FEATURE_MASK(FEATURE_DS_DCEFCLK_BIT)
>  | FEATURE_MASK(FEATURE_FW_DSTATE_BIT)
>  | FEATURE_MASK(FEATURE_BACO_BIT)
>  | FEATURE_MASK(FEATURE_ACDC_BIT)
>  | FEATURE_MASK(FEATURE_GFX_SS_BIT)
>  | FEATURE_MASK(FEATURE_APCC_DFLL_BIT)
> -   | FEATURE_MASK(FEATURE_FW_CTF_BIT);
> +   | FEATURE_MASK(FEATURE_FW_CTF_BIT)
> +   | 
> FEATURE_MASK(FEATURE_OUT_OF_BAND_MONITOR_BIT);
>
>  if (adev->pm.pp_feature & PP_MCLK_DPM_MASK)
>  *(uint64_t *)feature_mask |= 
> FEATURE_MASK(FEATURE_DPM_UCLK_BIT)
> --
> 2.20.1
>
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 1/2] drm/amd/powerplay: add more feature bits

[Alex Deucher]

Acked-by: Alex Deucher 

On Wed, Oct 9, 2019 at 10:25 PM Yuan, Xiaojie  wrote:
>
> Ping ...
>
> BR,
> Xiaojie
> 
> From: Yuan, Xiaojie 
> Sent: Wednesday, October 9, 2019 7:08 PM
> To: amd-gfx@lists.freedesktop.org 
> Cc: Zhang, Hawking ; Xiao, Jack ; 
> Feng, Kenneth ; Quan, Evan ; Wang, 
> Kevin(Yang) ; Yuan, Xiaojie 
> Subject: [PATCH 1/2] drm/amd/powerplay: add more feature bits
>
> Signed-off-by: Xiaojie Yuan 
> ---
>  drivers/gpu/drm/amd/powerplay/navi10_ppt.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/navi10_ppt.c 
> b/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
> index 5a34d01f7f7c..44152c1f01c7 100644
> --- a/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
> +++ b/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
> @@ -337,19 +337,22 @@ navi10_get_allowed_feature_mask(struct smu_context *smu,
>  | FEATURE_MASK(FEATURE_PPT_BIT)
>  | FEATURE_MASK(FEATURE_TDC_BIT)
>  | FEATURE_MASK(FEATURE_GFX_EDC_BIT)
> +   | FEATURE_MASK(FEATURE_APCC_PLUS_BIT)
>  | FEATURE_MASK(FEATURE_VR0HOT_BIT)
>  | FEATURE_MASK(FEATURE_FAN_CONTROL_BIT)
>  | FEATURE_MASK(FEATURE_THERMAL_BIT)
>  | FEATURE_MASK(FEATURE_LED_DISPLAY_BIT)
>  | FEATURE_MASK(FEATURE_DPM_DCEFCLK_BIT)
>  | FEATURE_MASK(FEATURE_DS_GFXCLK_BIT)
> +   | FEATURE_MASK(FEATURE_DS_LCLK_BIT)
>  | FEATURE_MASK(FEATURE_DS_DCEFCLK_BIT)
>  | FEATURE_MASK(FEATURE_FW_DSTATE_BIT)
>  | FEATURE_MASK(FEATURE_BACO_BIT)
>  | FEATURE_MASK(FEATURE_ACDC_BIT)
>  | FEATURE_MASK(FEATURE_GFX_SS_BIT)
>  | FEATURE_MASK(FEATURE_APCC_DFLL_BIT)
> -   | FEATURE_MASK(FEATURE_FW_CTF_BIT);
> +   | FEATURE_MASK(FEATURE_FW_CTF_BIT)
> +   | 
> FEATURE_MASK(FEATURE_OUT_OF_BAND_MONITOR_BIT);
>
>  if (adev->pm.pp_feature & PP_MCLK_DPM_MASK)
>  *(uint64_t *)feature_mask |= 
> FEATURE_MASK(FEATURE_DPM_UCLK_BIT)
> --
> 2.20.1
>
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 1/2] drm/amd/powerplay: add more feature bits

[Yuan, Xiaojie]

Ping ...

BR,
Xiaojie

From: Yuan, Xiaojie 
Sent: Wednesday, October 9, 2019 7:08 PM
To: amd-gfx@lists.freedesktop.org 
Cc: Zhang, Hawking ; Xiao, Jack ; 
Feng, Kenneth ; Quan, Evan ; Wang, 
Kevin(Yang) ; Yuan, Xiaojie 
Subject: [PATCH 1/2] drm/amd/powerplay: add more feature bits

Signed-off-by: Xiaojie Yuan 
---
 drivers/gpu/drm/amd/powerplay/navi10_ppt.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/powerplay/navi10_ppt.c 
b/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
index 5a34d01f7f7c..44152c1f01c7 100644
--- a/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
+++ b/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
@@ -337,19 +337,22 @@ navi10_get_allowed_feature_mask(struct smu_context *smu,
 | FEATURE_MASK(FEATURE_PPT_BIT)
 | FEATURE_MASK(FEATURE_TDC_BIT)
 | FEATURE_MASK(FEATURE_GFX_EDC_BIT)
+   | FEATURE_MASK(FEATURE_APCC_PLUS_BIT)
 | FEATURE_MASK(FEATURE_VR0HOT_BIT)
 | FEATURE_MASK(FEATURE_FAN_CONTROL_BIT)
 | FEATURE_MASK(FEATURE_THERMAL_BIT)
 | FEATURE_MASK(FEATURE_LED_DISPLAY_BIT)
 | FEATURE_MASK(FEATURE_DPM_DCEFCLK_BIT)
 | FEATURE_MASK(FEATURE_DS_GFXCLK_BIT)
+   | FEATURE_MASK(FEATURE_DS_LCLK_BIT)
 | FEATURE_MASK(FEATURE_DS_DCEFCLK_BIT)
 | FEATURE_MASK(FEATURE_FW_DSTATE_BIT)
 | FEATURE_MASK(FEATURE_BACO_BIT)
 | FEATURE_MASK(FEATURE_ACDC_BIT)
 | FEATURE_MASK(FEATURE_GFX_SS_BIT)
 | FEATURE_MASK(FEATURE_APCC_DFLL_BIT)
-   | FEATURE_MASK(FEATURE_FW_CTF_BIT);
+   | FEATURE_MASK(FEATURE_FW_CTF_BIT)
+   | FEATURE_MASK(FEATURE_OUT_OF_BAND_MONITOR_BIT);

 if (adev->pm.pp_feature & PP_MCLK_DPM_MASK)
 *(uint64_t *)feature_mask |= FEATURE_MASK(FEATURE_DPM_UCLK_BIT)
--
2.20.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amdgpu/swSMU/navi: add feature toggles for more things

[Kevin Wang]

Reviewed-by: Kevin Wang 

Best Regards,
Kevin

On 10/9/19 9:17 PM, Alex Deucher wrote:
> Add toggles for more power features.  Helpful in debugging.
>
> Signed-off-by: Alex Deucher 
> ---
>   drivers/gpu/drm/amd/powerplay/navi10_ppt.c | 24 --
>   1 file changed, 18 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/navi10_ppt.c 
> b/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
> index a583cf87b514..8e1f3be8ba6f 100644
> --- a/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
> +++ b/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
> @@ -328,11 +328,7 @@ navi10_get_allowed_feature_mask(struct smu_context *smu,
>   memset(feature_mask, 0, sizeof(uint32_t) * num);
>   
>   *(uint64_t *)feature_mask |= FEATURE_MASK(FEATURE_DPM_PREFETCHER_BIT)
> - | FEATURE_MASK(FEATURE_DPM_GFXCLK_BIT)
> - | FEATURE_MASK(FEATURE_DPM_SOCCLK_BIT)
>   | FEATURE_MASK(FEATURE_DPM_MP0CLK_BIT)
> - | FEATURE_MASK(FEATURE_DPM_LINK_BIT)
> - | FEATURE_MASK(FEATURE_GFX_ULV_BIT)
>   | FEATURE_MASK(FEATURE_RSMU_SMN_CG_BIT)
>   | FEATURE_MASK(FEATURE_DS_SOCCLK_BIT)
>   | FEATURE_MASK(FEATURE_PPT_BIT)
> @@ -342,8 +338,6 @@ navi10_get_allowed_feature_mask(struct smu_context *smu,
>   | FEATURE_MASK(FEATURE_FAN_CONTROL_BIT)
>   | FEATURE_MASK(FEATURE_THERMAL_BIT)
>   | FEATURE_MASK(FEATURE_LED_DISPLAY_BIT)
> - | FEATURE_MASK(FEATURE_DPM_DCEFCLK_BIT)
> - | FEATURE_MASK(FEATURE_DS_GFXCLK_BIT)
>   | FEATURE_MASK(FEATURE_DS_DCEFCLK_BIT)
>   | FEATURE_MASK(FEATURE_FW_DSTATE_BIT)
>   | FEATURE_MASK(FEATURE_BACO_BIT)
> @@ -352,11 +346,29 @@ navi10_get_allowed_feature_mask(struct smu_context *smu,
>   | FEATURE_MASK(FEATURE_APCC_DFLL_BIT)
>   | FEATURE_MASK(FEATURE_FW_CTF_BIT);
>   
> + if (adev->pm.pp_feature & PP_SOCCLK_DPM_MASK)
> + *(uint64_t *)feature_mask |= 
> FEATURE_MASK(FEATURE_DPM_SOCCLK_BIT);
> +
> + if (adev->pm.pp_feature & PP_SCLK_DPM_MASK)
> + *(uint64_t *)feature_mask |= 
> FEATURE_MASK(FEATURE_DPM_GFXCLK_BIT);
> +
> + if (adev->pm.pp_feature & PP_PCIE_DPM_MASK)
> + *(uint64_t *)feature_mask |= FEATURE_MASK(FEATURE_DPM_LINK_BIT);
> +
> + if (adev->pm.pp_feature & PP_DCEFCLK_DPM_MASK)
> + *(uint64_t *)feature_mask |= 
> FEATURE_MASK(FEATURE_DPM_DCEFCLK_BIT);
> +
>   if (adev->pm.pp_feature & PP_MCLK_DPM_MASK)
>   *(uint64_t *)feature_mask |= FEATURE_MASK(FEATURE_DPM_UCLK_BIT)
>   | FEATURE_MASK(FEATURE_MEM_VDDCI_SCALING_BIT)
>   | FEATURE_MASK(FEATURE_MEM_MVDD_SCALING_BIT);
>   
> + if (adev->pm.pp_feature & PP_ULV_MASK)
> + *(uint64_t *)feature_mask |= FEATURE_MASK(FEATURE_GFX_ULV_BIT);
> +
> + if (adev->pm.pp_feature & PP_SCLK_DEEP_SLEEP_MASK)
> + *(uint64_t *)feature_mask |= 
> FEATURE_MASK(FEATURE_DS_GFXCLK_BIT);
> +
>   if (adev->pm.pp_feature & PP_GFXOFF_MASK) {
>   *(uint64_t *)feature_mask |= FEATURE_MASK(FEATURE_GFXOFF_BIT);
>   /* TODO: remove it once fw fix the bug */
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

RE: [PATCH] drm/amdgpu/swSMU/navi: add feature toggles for more things

[Quan, Evan]

Reviewed-by: Evan Quan 

-Original Message-
From: amd-gfx  On Behalf Of Alex Deucher
Sent: Wednesday, October 9, 2019 9:17 PM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander 
Subject: [PATCH] drm/amdgpu/swSMU/navi: add feature toggles for more things

Add toggles for more power features.  Helpful in debugging.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/powerplay/navi10_ppt.c | 24 --
 1 file changed, 18 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/navi10_ppt.c 
b/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
index a583cf87b514..8e1f3be8ba6f 100644
--- a/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
+++ b/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
@@ -328,11 +328,7 @@ navi10_get_allowed_feature_mask(struct smu_context *smu,
memset(feature_mask, 0, sizeof(uint32_t) * num);
 
*(uint64_t *)feature_mask |= FEATURE_MASK(FEATURE_DPM_PREFETCHER_BIT)
-   | FEATURE_MASK(FEATURE_DPM_GFXCLK_BIT)
-   | FEATURE_MASK(FEATURE_DPM_SOCCLK_BIT)
| FEATURE_MASK(FEATURE_DPM_MP0CLK_BIT)
-   | FEATURE_MASK(FEATURE_DPM_LINK_BIT)
-   | FEATURE_MASK(FEATURE_GFX_ULV_BIT)
| FEATURE_MASK(FEATURE_RSMU_SMN_CG_BIT)
| FEATURE_MASK(FEATURE_DS_SOCCLK_BIT)
| FEATURE_MASK(FEATURE_PPT_BIT)
@@ -342,8 +338,6 @@ navi10_get_allowed_feature_mask(struct smu_context *smu,
| FEATURE_MASK(FEATURE_FAN_CONTROL_BIT)
| FEATURE_MASK(FEATURE_THERMAL_BIT)
| FEATURE_MASK(FEATURE_LED_DISPLAY_BIT)
-   | FEATURE_MASK(FEATURE_DPM_DCEFCLK_BIT)
-   | FEATURE_MASK(FEATURE_DS_GFXCLK_BIT)
| FEATURE_MASK(FEATURE_DS_DCEFCLK_BIT)
| FEATURE_MASK(FEATURE_FW_DSTATE_BIT)
| FEATURE_MASK(FEATURE_BACO_BIT)
@@ -352,11 +346,29 @@ navi10_get_allowed_feature_mask(struct smu_context *smu,
| FEATURE_MASK(FEATURE_APCC_DFLL_BIT)
| FEATURE_MASK(FEATURE_FW_CTF_BIT);
 
+   if (adev->pm.pp_feature & PP_SOCCLK_DPM_MASK)
+   *(uint64_t *)feature_mask |= 
FEATURE_MASK(FEATURE_DPM_SOCCLK_BIT);
+
+   if (adev->pm.pp_feature & PP_SCLK_DPM_MASK)
+   *(uint64_t *)feature_mask |= 
FEATURE_MASK(FEATURE_DPM_GFXCLK_BIT);
+
+   if (adev->pm.pp_feature & PP_PCIE_DPM_MASK)
+   *(uint64_t *)feature_mask |= FEATURE_MASK(FEATURE_DPM_LINK_BIT);
+
+   if (adev->pm.pp_feature & PP_DCEFCLK_DPM_MASK)
+   *(uint64_t *)feature_mask |= 
FEATURE_MASK(FEATURE_DPM_DCEFCLK_BIT);
+
if (adev->pm.pp_feature & PP_MCLK_DPM_MASK)
*(uint64_t *)feature_mask |= FEATURE_MASK(FEATURE_DPM_UCLK_BIT)
| FEATURE_MASK(FEATURE_MEM_VDDCI_SCALING_BIT)
| FEATURE_MASK(FEATURE_MEM_MVDD_SCALING_BIT);
 
+   if (adev->pm.pp_feature & PP_ULV_MASK)
+   *(uint64_t *)feature_mask |= FEATURE_MASK(FEATURE_GFX_ULV_BIT);
+
+   if (adev->pm.pp_feature & PP_SCLK_DEEP_SLEEP_MASK)
+   *(uint64_t *)feature_mask |= 
FEATURE_MASK(FEATURE_DS_GFXCLK_BIT);
+
if (adev->pm.pp_feature & PP_GFXOFF_MASK) {
*(uint64_t *)feature_mask |= FEATURE_MASK(FEATURE_GFXOFF_BIT);
/* TODO: remove it once fw fix the bug */
-- 
2.20.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 13/14] drm/amd/display: Recalculate VCPI slots for new DSC connectors

[Lyude Paul]

On Tue, 2019-10-08 at 21:26 +, Mikita Lipski wrote:
> 
> On 08.10.2019 12:24, Lyude Paul wrote:
> > ...
> > yikes
> > I need to apologize because I was going through my email and I realized
> > you
> > _did_ respond to me earlier regarding some of these questions, it just
> > appears
> > the reply fell through the cracks and somehow I didn't notice it until
> > just
> > now. Sorry about that!
> > 
> No worries, the patches got messy and are easily lost in here. I'll 
> clean up on the next batch so it will be clearer what's happening
> 
> > I'm still not sure I understand why this is a future enhancement?
> > Everything
> > we need to implement these helpers should already be here, it's just a
> > matter
> > of keeping track who has dsc enabled where in the mst atomic state
> 
> As I've mentioned earlier our policy for DSC is to keep it disabled if 
> not needed, because it is a lossy compression. Beside the fact that we 
> don't want imperfect image on the screen, enabling DSC would also 
> increase our power consumption. If we need it - we use the  greedy 
> algorithm inside compute_mst_dsc_configs_for_link to only enable DSC on 
> streams that can't fit into allowed bandwidth without compression.
> 
> I'm not exactly sure how it can be moved as helper to DRM.
> We keep track on which stream has DSC enabled by raising DSC flag in 
> dc_stream_state flags structure.
> That it why pbn recalculation was moved to a separate function so only 
> streams that have DSC flag raised get VCPI recalculated.
> 
> I guess if we would have dsc_desired flag on drm_connnector_state and it 
> would then perform recalculation of PBN and VCPI for the connector. 
> Would that be something applicable as a DRM helper?

This would probably be a better fit for drm_dp_mst_topology_mgr's atomic state
(take a look at the atomic VCPI helpers), specifically in struct
drm_dp_mst_vcpi (maybe we should rename it to struct drm_dp_mst_port_bw while
we're at it) and store DSC enablement information there. Then we can write a
helper to go through all of the enabled ports on the topology and add the
affected ones into the atomic state and set ->mode_changed on all of them.
> 
> 
> > On Mon, 2019-10-07 at 17:52 -0400, Lyude Paul wrote:
> > > Ok, let's stop and slow down for a minute here since I've repeated
> > > myself a
> > > few times, and I'd like to figure out what's actually happening here and
> > > whether I'm not being clear enough with my explanations, or if there's
> > > just
> > > some misunderstanding here.
> > > 
> > > I'll start of by trying my best to explain my hesistance in accepting
> > > these
> > > patches. To be clear, MST with DSC is a big thing in terms of impact.
> > > There's
> > > a lot of things to consider:
> > >   * What should the default DSC policy for MST be? Should we keep it on
> > > by
> > > default so that we don't need to trigger a large number of PBN
> > > recalculations and enable DSC on a per-case basis, or are there
> > > legitimate
> > > reasons to keep DSC off by default (such as potential issues with
> > > lossiness
> > > down the line).
> > >   * We have other drivers in the tree that are planning on implementing
> > > MST
> > > DSC
> > > quite soon. Chances are they'll be implementing helpers to do this
> > > so
> > > this
> > > can be supported across the DRM tree, and chances are we'll just
> > > have to
> > > rewrite and remove most of this code in that case once they do.
> > >   * amdgpu already has a _lot_ of code that doesn't need to, and
> > > shouldn't be
> > > there. This ranges from various DC specific helpers that are
> > > essentially
> > > the same as the helpers that we already implement in the rest of
> > > DRM, to
> > > misuses of various kernel APIs, and a complete lack of any kind of
> > > code
> > > style (at least the last time that I checked) in or out of DC. This
> > > makes
> > > the driver more difficult for people who don't work at AMD but are
> > > well
> > > accustomed to working on the rest of the kernel, e.g. myself and
> > > others,
> > > and it's a problem that seriously needs to be solved. Adding more
> > > redundant
> > > DP helpers that will inevitably get removed is just making the
> > > problem
> > > worse.
> > > 
> > > With all of this being said: I've been asking the same questions about
> > > this
> > > patch throughout the whole patch series so far (since it got passed off
> > > to
> > > you
> > > from David's internship ending):
> > > 
> > >   * Can we keep DSC enabled by default, so that these patches aren't
> > > needed?
> > >   * If we can't, can we move this into common code so that other drivers
> > > can
> > > use it?
> > > The problem is I haven't received any responses to these questions,
> > > other
> > > then
> > > being told by David a month or two ago that it would be expedient to
> > > just
> > > accept the patches and move on. Honestly, if discussion had been had
> > > 

Stack alignment of DC functions

[Yuxuan Shui]

Hi,

When trying to build a Linux kernel with clang, I encountered a GPF
problem in the amdgpu module. Details of the issue can be found here:
https://github.com/ClangBuiltLinux/linux/issues/735

In short, the stack is aligned to 8 bytes while clang assumed the
stack is aligned to 16 bytes (because -mstack-alignment=16 is passed),
and generated an unaligned MOVAPD.

My question is, how is this supposed to work? To my understanding, gcc
option -mpreferred-stack-boundary does not align the stack, it simply
make gcc assume the stack alignment. Passing
-mpreferred-stack-boundary=4 to DC code seems to be wrong since the
actual stack alignment is only 8 bytes. Yet this GPF has not been
observed when compiling the kernel with gcc.

I don't really understand.

-- 

Regards
Yuxuan Shui
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 23/26] drm/amd/display: add sanity check for clk table from smu

[Bhawanpreet Lakha]

From: Eric Yang 

[Why]
Handle the case where we don't get a valid table. Also fixes compiler
warning for variable potentially used before assignment.

[How]
If the entire table has no valid fclk, reject the table and use our own
hard code.

Signed-off-by: Eric Yang 
Acked-by: Bhawanpreet Lakha 
---
 drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c 
b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c
index fb8aa9436bf0..0e712df87109 100644
--- a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c
+++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c
@@ -546,6 +546,8 @@ void rn_clk_mgr_helper_populate_bw_params(struct 
clk_bw_params *bw_params, struc
 {
int i, j = 0;
 
+   j = -1;
+
ASSERT(PP_SMU_NUM_FCLK_DPM_LEVELS <= MAX_NUM_DPM_LVL);
 
/* Find lowest DPM, FCLK is filled in reverse order*/
@@ -557,6 +559,12 @@ void rn_clk_mgr_helper_populate_bw_params(struct 
clk_bw_params *bw_params, struc
}
}
 
+   if (j == -1) {
+   /* clock table is all 0s, just use our own hardcode */
+   ASSERT(0);
+   return;
+   }
+
bw_params->clk_table.num_entries = j + 1;
 
for (i = 0; i < bw_params->clk_table.num_entries; i++, j--) {
-- 
2.17.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 24/26] drm/amd/display: fix header for RN clk mgr

[Bhawanpreet Lakha]

From: joseph gravenor 

[why]
Should always MP0_BASE for any register definition from MP per-IP header files.
I belive the reason the linux version of MP1_BASE works is The 0th element of 
the 0th table
of that is identical to the corrisponding value of MP0_BASE in the renoir 
offset header file.
The reason we should only use MP0_BASE is There is only one set of per-IP 
headers MP
that includes all register definitions related to SMU IP block. This IP 
includes MP0, MP1, MP2
and  an ecryption engine that can be used only by MP0. As a result all register 
definitions from
MP file should be based only on MP0_BASE data.

[How]
Change MP1_BASE to MP0_BASE

Signed-off-by: joseph gravenor 
Acked-by: Bhawanpreet Lakha 
---
 .../gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr_vbios_smu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr_vbios_smu.c 
b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr_vbios_smu.c
index 8e860f567d5c..db28e91adb3d 100644
--- a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr_vbios_smu.c
+++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr_vbios_smu.c
@@ -33,7 +33,7 @@
 #include "mp/mp_12_0_0_sh_mask.h"
 
 #define REG(reg_name) \
-   (MP1_BASE.instance[0].segment[mm ## reg_name ## _BASE_IDX] + mm ## 
reg_name)
+   (MP0_BASE.instance[0].segment[mm ## reg_name ## _BASE_IDX] + mm ## 
reg_name)
 
 #define FN(reg_name, field) \
FD(reg_name##__##field)
-- 
2.17.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 00/26] Renoir DC Patches

[Bhawanpreet Lakha]

Hi all,

There was a delta betwwen internal dcn21 code and upstream dcn21 code.
These changes bring them inline.


Summary of Changes
*Add RN registors
*Add dcn12 hwseq and link_encoder
*RN specific fixes
*aux timeout support
*bounding box changes

Bhawanpreet Lakha (12):
  drm/amd/display: Add DP_DPHY_INTERNAL_CTR regs
  drm/amd/display: Add DCN_BASE regs
  drm/amd/display: Add renoir hw_seq
  drm/amd/display: create dcn21_link_encoder files
  drm/amd/display: add REFCYC_PER_TRIP_TO_MEMORY programming
  drm/amd/display: fix incorrect page table address for renoir
  drm/amd/display: add detile buffer size for renoir
  drm/amd/display: update dcn21 hubbub registers
  drm/amd/display: update renoir bounding box and res_caps
  drm/amd/display: change PP_SM defs to 8
  drm/amd/display: handle "18" case in TruncToValidBPP
  drm/amd/display: use requested_dispclk_khz instead of clk

Dmytro Laktyushkin (4):
  drm/amd/display: enable hostvm based on roimmu active for dcn2.1
  drm/amd/display: initialize RN gpuvm context programming function
  drm/amd/display: correct dcn21 NUM_VMID to 16
  drm/amd/display: update odm mode validation to be in line with policy

Eric Yang (2):
  drm/amd/display: use dcn10 version of program tiling on Renoir
  drm/amd/display: add sanity check for clk table from smu

Lewis Huang (3):
  drm/amd/display: move the bounding box patch before calculate wm
  drm/amd/display: Temporary workaround to toggle watermark setting
  drm/amd/display: enable smu set dcfclk

Michael Strauss (1):
  drm/amd/display: Fix rn audio playback and video playback speed

Sung Lee (1):
  drm/amd/display: add dummy functions to smu for Renoir Silicon Diags

abdoulaye berthe (2):
  drm/amd/display: update register field access mechanism
  drm/amd/display: configurable aux timeout support

joseph gravenor (1):
  drm/amd/display: fix header for RN clk mgr

 .../amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c |  23 +-
 .../dc/clk_mgr/dcn21/rn_clk_mgr_vbios_smu.c   |  19 +-
 .../gpu/drm/amd/display/dc/core/dc_link_ddc.c |  14 +
 drivers/gpu/drm/amd/display/dc/dc.h   |   2 +
 drivers/gpu/drm/amd/display/dc/dce/dce_aux.c  |  82 +++-
 drivers/gpu/drm/amd/display/dc/dce/dce_aux.h  | 187 -
 .../gpu/drm/amd/display/dc/dce/dce_hwseq.h|   1 +
 .../amd/display/dc/dce100/dce100_resource.c   |  15 +-
 .../amd/display/dc/dce110/dce110_resource.c   |  14 +-
 .../amd/display/dc/dce112/dce112_resource.c   |  15 +-
 .../amd/display/dc/dce120/dce120_resource.c   |  15 +-
 .../drm/amd/display/dc/dce80/dce80_resource.c |  14 +-
 .../amd/display/dc/dcn10/dcn10_hw_sequencer.c |   4 +
 .../amd/display/dc/dcn10/dcn10_link_encoder.h |  35 +-
 .../drm/amd/display/dc/dcn10/dcn10_resource.c |  15 +-
 .../drm/amd/display/dc/dcn20/dcn20_hwseq.c|   4 +
 .../amd/display/dc/dcn20/dcn20_link_encoder.h |   7 +
 .../drm/amd/display/dc/dcn20/dcn20_resource.c |  31 +-
 drivers/gpu/drm/amd/display/dc/dcn21/Makefile |   2 +-
 .../drm/amd/display/dc/dcn21/dcn21_hubbub.c   | 116 --
 .../drm/amd/display/dc/dcn21/dcn21_hubbub.h   |  34 +-
 .../gpu/drm/amd/display/dc/dcn21/dcn21_hubp.c |   4 +-
 .../drm/amd/display/dc/dcn21/dcn21_hwseq.c| 122 ++
 .../drm/amd/display/dc/dcn21/dcn21_hwseq.h|  33 ++
 .../amd/display/dc/dcn21/dcn21_link_encoder.c | 384 ++
 .../amd/display/dc/dcn21/dcn21_link_encoder.h |  51 +++
 .../drm/amd/display/dc/dcn21/dcn21_resource.c | 269 ++--
 drivers/gpu/drm/amd/display/dc/dm_pp_smu.h|   6 +-
 .../dc/dml/dcn21/display_mode_vba_21.c|  11 +-
 .../gpu/drm/amd/display/dc/inc/dc_link_ddc.h  |   3 +
 .../gpu/drm/amd/display/dc/inc/dc_link_dp.h   |   2 +
 .../drm/amd/display/dc/inc/hw/aux_engine.h|   3 +
 .../gpu/drm/amd/display/dc/inc/hw/dchubbub.h  |   1 +
 .../gpu/drm/amd/display/dc/inc/hw/mem_input.h |   1 +
 .../gpu/drm/amd/display/dc/inc/hw_sequencer.h |   3 +
 .../include/asic_reg/dcn/dcn_2_1_0_offset.h   |  10 +
 .../gpu/drm/amd/include/renoir_ip_offset.h|  34 ++
 37 files changed, 1461 insertions(+), 125 deletions(-)
 create mode 100644 drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hwseq.c
 create mode 100644 drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hwseq.h
 create mode 100644 drivers/gpu/drm/amd/display/dc/dcn21/dcn21_link_encoder.c
 create mode 100644 drivers/gpu/drm/amd/display/dc/dcn21/dcn21_link_encoder.h

-- 
2.17.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 11/26] drm/amd/display: Temporary workaround to toggle watermark setting

[Bhawanpreet Lakha]

From: Lewis Huang 

[Why]
Watermarks not propagated to DCHUBP after it is powered on

[How]
Add temoprary function apply_DEDCN21_147_wa to apply wm settings for Renoir

Signed-off-by: Lewis Huang 
Reviewed-by: Tony Cheng 
Acked-by: Bhawanpreet Lakha 
---
 drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c| 4 
 drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hubbub.c   | 9 +
 drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c | 1 +
 drivers/gpu/drm/amd/display/dc/inc/hw/dchubbub.h  | 1 +
 4 files changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c 
b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c
index ce2530509e12..6229a8ca0013 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c
@@ -1533,6 +1533,10 @@ static void dcn20_program_front_end_for_ctx(
msleep(1);
}
}
+
+   /* WA to apply WM setting*/
+   if (dc->hwseq->wa.DEGVIDCN21)
+   
dc->res_pool->hubbub->funcs->apply_DEDCN21_147_wa(dc->res_pool->hubbub);
 }
 
 
diff --git a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hubbub.c 
b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hubbub.c
index fdfbdeb32459..2232ccf14bdd 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hubbub.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hubbub.c
@@ -616,6 +616,14 @@ void hubbub21_wm_read_state(struct hubbub *hubbub,
DCHUBBUB_ARB_ALLOW_DRAM_CLK_CHANGE_WATERMARK_D, 
>dram_clk_chanage);
 }
 
+void hubbub21_apply_DEDCN21_147_wa(struct hubbub *hubbub)
+{
+   struct dcn20_hubbub *hubbub1 = TO_DCN20_HUBBUB(hubbub);
+   uint32_t prog_wm_value;
+
+   prog_wm_value = REG_READ(DCHUBBUB_ARB_DATA_URGENCY_WATERMARK_A);
+   REG_WRITE(DCHUBBUB_ARB_DATA_URGENCY_WATERMARK_A, prog_wm_value);
+}
 
 static const struct hubbub_funcs hubbub21_funcs = {
.update_dchub = hubbub2_update_dchub,
@@ -627,6 +635,7 @@ static const struct hubbub_funcs hubbub21_funcs = {
.wm_read_state = hubbub21_wm_read_state,
.get_dchub_ref_freq = hubbub2_get_dchub_ref_freq,
.program_watermarks = hubbub21_program_watermarks,
+   .apply_DEDCN21_147_wa = hubbub21_apply_DEDCN21_147_wa,
 };
 
 void hubbub21_construct(struct dcn20_hubbub *hubbub,
diff --git a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c 
b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
index e39961d0f24e..5e15f800a9f1 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
@@ -1468,6 +1468,7 @@ static struct dce_hwseq *dcn21_hwseq_create(
hws->regs = _reg;
hws->shifts = _shift;
hws->masks = _mask;
+   hws->wa.DEGVIDCN21 = true;
}
return hws;
 }
diff --git a/drivers/gpu/drm/amd/display/dc/inc/hw/dchubbub.h 
b/drivers/gpu/drm/amd/display/dc/inc/hw/dchubbub.h
index a6297219d7fc..c81a17aeaa25 100644
--- a/drivers/gpu/drm/amd/display/dc/inc/hw/dchubbub.h
+++ b/drivers/gpu/drm/amd/display/dc/inc/hw/dchubbub.h
@@ -147,6 +147,7 @@ struct hubbub_funcs {
bool (*is_allow_self_refresh_enabled)(struct hubbub *hubbub);
void (*allow_self_refresh_control)(struct hubbub *hubbub, bool allow);
 
+   void (*apply_DEDCN21_147_wa)(struct hubbub *hubbub);
 };
 
 struct hubbub {
-- 
2.17.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 05/26] drm/amd/display: Add renoir hw_seq

[Bhawanpreet Lakha]

This change adds renoir hw_seq, needed to do renoir
specific hw programing

Signed-off-by: Bhawanpreet Lakha 
---
 .../gpu/drm/amd/display/dc/dce/dce_hwseq.h|   1 +
 .../amd/display/dc/dcn10/dcn10_hw_sequencer.c |   4 +
 drivers/gpu/drm/amd/display/dc/dcn21/Makefile |   2 +-
 .../drm/amd/display/dc/dcn21/dcn21_hwseq.c| 122 ++
 .../drm/amd/display/dc/dcn21/dcn21_hwseq.h|  33 +
 .../drm/amd/display/dc/dcn21/dcn21_resource.c | 118 +
 .../gpu/drm/amd/display/dc/inc/hw_sequencer.h |   3 +
 7 files changed, 255 insertions(+), 28 deletions(-)
 create mode 100644 drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hwseq.c
 create mode 100644 drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hwseq.h

diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_hwseq.h 
b/drivers/gpu/drm/amd/display/dc/dce/dce_hwseq.h
index ac04d77058f0..32d145a0d6fc 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dce_hwseq.h
+++ b/drivers/gpu/drm/amd/display/dc/dce/dce_hwseq.h
@@ -679,6 +679,7 @@ struct dce_hwseq_registers {
HWS_SF(, DOMAIN17_PG_STATUS, DOMAIN17_PGFSM_PWR_STATUS, mask_sh), \
HWS_SF(, DOMAIN18_PG_STATUS, DOMAIN18_PGFSM_PWR_STATUS, mask_sh), \
HWS_SF(, DC_IP_REQUEST_CNTL, IP_REQUEST_EN, mask_sh), \
+   HWSEQ_LVTMA_MASK_SH_LIST(mask_sh), \
HWS_SF(, LVTMA_PWRSEQ_CNTL, LVTMA_BLON, mask_sh), \
HWS_SF(, LVTMA_PWRSEQ_STATE, LVTMA_PWRSEQ_TARGET_STATE_R, mask_sh)
 #endif
diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c 
b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
index 32bf6cf09677..df1be8ada66d 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
@@ -670,6 +670,10 @@ static void dcn10_bios_golden_init(struct dc *dc)
int i;
bool allow_self_fresh_force_enable = true;
 
+#if defined(CONFIG_DRM_AMD_DC_DCN2_1)
+   if (dc->hwss.s0i3_golden_init_wa && dc->hwss.s0i3_golden_init_wa(dc))
+   return;
+#endif
if (dc->res_pool->hubbub->funcs->is_allow_self_refresh_enabled)
allow_self_fresh_force_enable =

dc->res_pool->hubbub->funcs->is_allow_self_refresh_enabled(dc->res_pool->hubbub);
diff --git a/drivers/gpu/drm/amd/display/dc/dcn21/Makefile 
b/drivers/gpu/drm/amd/display/dc/dcn21/Makefile
index b2b39090fb57..5b8f42ae2334 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn21/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dcn21/Makefile
@@ -1,7 +1,7 @@
 #
 # Makefile for DCN21.
 
-DCN21 = dcn21_hubp.o dcn21_hubbub.o dcn21_resource.o
+DCN21 = dcn21_hubp.o dcn21_hubbub.o dcn21_resource.o dcn21_hwseq.o
 
 CFLAGS_dcn21_resource.o := -mhard-float -msse -mpreferred-stack-boundary=4
 
diff --git a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hwseq.c 
b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hwseq.c
new file mode 100644
index ..b25215cadf85
--- /dev/null
+++ b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hwseq.c
@@ -0,0 +1,122 @@
+/*
+ * Copyright 2016 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 "dm_services.h"
+#include "dm_helpers.h"
+#include "core_types.h"
+#include "resource.h"
+#include "dce/dce_hwseq.h"
+#include "dcn20/dcn20_hwseq.h"
+#include "vmid.h"
+#include "reg_helper.h"
+#include "hw/clk_mgr.h"
+
+
+#define DC_LOGGER_INIT(logger)
+
+#define CTX \
+   hws->ctx
+#define REG(reg)\
+   hws->regs->reg
+
+#undef FN
+#define FN(reg_name, field_name) \
+   hws->shifts->field_name, hws->masks->field_name
+
+/* Temporary read settings, future will get values from kmd directly */
+static void mmhub_update_page_table_config(struct dcn_hubbub_phys_addr_config 
*config,
+   struct dce_hwseq *hws)
+{
+   uint32_t page_table_base_hi;
+   uint32_t page_table_base_lo;
+
+   REG_GET(VM_CONTEXT0_PAGE_TABLE_BASE_ADDR_HI32,
+  

[PATCH 14/26] drm/amd/display: correct dcn21 NUM_VMID to 16

[Bhawanpreet Lakha]

From: Dmytro Laktyushkin 

1 vmid limitation only exists for HOSTVM which is a custom
use case anyway.

Signed-off-by: Dmytro Laktyushkin 
Acked-by: Bhawanpreet Lakha 
---
 drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hubbub.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hubbub.c 
b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hubbub.c
index 44f64a8e33f1..aeb5de6f4530 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hubbub.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hubbub.c
@@ -52,7 +52,7 @@
 #ifdef NUM_VMID
 #undef NUM_VMID
 #endif
-#define NUM_VMID 1
+#define NUM_VMID 16
 
 static uint32_t convert_and_clamp(
uint32_t wm_ns,
-- 
2.17.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 20/26] drm/amd/display: update odm mode validation to be in line with policy

[Bhawanpreet Lakha]

From: Dmytro Laktyushkin 

Previously 8k30 worked with dsc and odm combine due to a workaround that ran
the formula a second time with dsc support enable should dsc validation fail.
This worked when clocks were low enough for formula to enable odm to lower
voltage, however now broke due to increased clocks.

This change updates the ODM combine policy within the formula to properly
reflect our current policy within DC, only enabling ODM when we have to, as
well as adding a check for viewport width when dsc is enabled.

As a side effect the redundant call to dml when odm is required is now
unnecessary.

Signed-off-by: Dmytro Laktyushkin 
Acked-by: Bhawanpreet Lakha 
---
 .../drm/amd/display/dc/dml/dcn21/display_mode_vba_21.c   | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn21/display_mode_vba_21.c 
b/drivers/gpu/drm/amd/display/dc/dml/dcn21/display_mode_vba_21.c
index 3b6ed60dcd35..fd707e7459b5 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn21/display_mode_vba_21.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn21/display_mode_vba_21.c
@@ -65,6 +65,7 @@ typedef struct {
 
 #define BPP_INVALID 0
 #define BPP_BLENDED_PIPE 0x
+#define DCN21_MAX_DSC_IMAGE_WIDTH 5184
 
 static void DisplayPipeConfiguration(struct display_mode_lib *mode_lib);
 static void 
DISPCLKDPPCLKDCFCLKDeepSleepPrefetchParametersWatermarksAndPerformanceCalculation(
@@ -3936,6 +3937,10 @@ void dml21_ModeSupportAndSystemConfigurationFull(struct 
display_mode_lib *mode_l
mode_lib->vba.MaximumSwathWidthInLineBuffer);
}
for (i = 0; i <= mode_lib->vba.soc.num_states; i++) {
+   double MaxMaxDispclkRoundedDown = RoundToDFSGranularityDown(
+   mode_lib->vba.MaxDispclk[mode_lib->vba.soc.num_states],
+   mode_lib->vba.DISPCLKDPPCLKVCOSpeed);
+
for (j = 0; j < 2; j++) {
mode_lib->vba.MaxDispclkRoundedDownToDFSGranularity = 
RoundToDFSGranularityDown(
mode_lib->vba.MaxDispclk[i],
@@ -3965,7 +3970,9 @@ void dml21_ModeSupportAndSystemConfigurationFull(struct 
display_mode_lib *mode_l
&& i == 
mode_lib->vba.soc.num_states)

mode_lib->vba.PlaneRequiredDISPCLKWithODMCombine = mode_lib->vba.PixelClock[k] 
/ 2
* (1 + 
mode_lib->vba.DISPCLKDPPCLKDSCCLKDownSpreading / 100.0);
-   if (mode_lib->vba.ODMCapability == false || 
mode_lib->vba.PlaneRequiredDISPCLKWithoutODMCombine <= 
mode_lib->vba.MaxDispclkRoundedDownToDFSGranularity) {
+   if (mode_lib->vba.ODMCapability == false ||
+   
(locals->PlaneRequiredDISPCLKWithoutODMCombine <= MaxMaxDispclkRoundedDown
+   && 
(!locals->DSCEnabled[k] || locals->HActive[k] <= DCN21_MAX_DSC_IMAGE_WIDTH))) {
locals->ODMCombineEnablePerState[i][k] 
= false;
mode_lib->vba.PlaneRequiredDISPCLK = 
mode_lib->vba.PlaneRequiredDISPCLKWithoutODMCombine;
} else {
-- 
2.17.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 08/26] drm/amd/display: move the bounding box patch before calculate wm

[Bhawanpreet Lakha]

From: Lewis Huang 

[why]
driver updateis the dcn2_1_soc into dml before call update_bw_bounding_box

[How]
Move the patch function before calculate wm.

Signed-off-by: Lewis Huang 
Signed-off-by: joseph graveno 
Acked-by: Bhawanpreet Lakha 
---
 .../drm/amd/display/dc/dcn21/dcn21_resource.c | 25 +++
 1 file changed, 25 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c 
b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
index ddf52e260ed6..e39961d0f24e 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
@@ -1007,6 +1007,29 @@ static void calculate_wm_set_for_vlevel(
 
 }
 
+static void patch_bounding_box(struct dc *dc, struct 
_vcs_dpi_soc_bounding_box_st *bb)
+{
+   kernel_fpu_begin();
+   if (dc->bb_overrides.sr_exit_time_ns) {
+   bb->sr_exit_time_us = dc->bb_overrides.sr_exit_time_ns / 1000.0;
+   }
+
+   if (dc->bb_overrides.sr_enter_plus_exit_time_ns) {
+   bb->sr_enter_plus_exit_time_us =
+   dc->bb_overrides.sr_enter_plus_exit_time_ns / 
1000.0;
+   }
+
+   if (dc->bb_overrides.urgent_latency_ns) {
+   bb->urgent_latency_us = dc->bb_overrides.urgent_latency_ns / 
1000.0;
+   }
+
+   if (dc->bb_overrides.dram_clock_change_latency_ns) {
+   bb->dram_clock_change_latency_us =
+   dc->bb_overrides.dram_clock_change_latency_ns / 
1000.0;
+   }
+   kernel_fpu_end();
+}
+
 void dcn21_calculate_wm(
struct dc *dc, struct dc_state *context,
display_e2e_pipe_params_st *pipes,
@@ -1021,6 +1044,8 @@ void dcn21_calculate_wm(
 
ASSERT(bw_params);
 
+   patch_bounding_box(dc, >bw_ctx.dml.soc);
+
for (i = 0, pipe_idx = 0, pipe_cnt = 0; i < dc->res_pool->pipe_count; 
i++) {
if (!context->res_ctx.pipe_ctx[i].stream)
continue;
-- 
2.17.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 12/26] drm/amd/display: initialize RN gpuvm context programming function

[Bhawanpreet Lakha]

From: Dmytro Laktyushkin 

Renoir can use vm contexes as long as HOSTVM is off so
this should be initialized.

Signed-off-by: Dmytro Laktyushkin 
Acked-by: Bhawanpreet Lakha 
---
 drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hubbub.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hubbub.c 
b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hubbub.c
index 2232ccf14bdd..44f64a8e33f1 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hubbub.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hubbub.c
@@ -628,7 +628,7 @@ void hubbub21_apply_DEDCN21_147_wa(struct hubbub *hubbub)
 static const struct hubbub_funcs hubbub21_funcs = {
.update_dchub = hubbub2_update_dchub,
.init_dchub_sys_ctx = hubbub21_init_dchub,
-   .init_vm_ctx = NULL,
+   .init_vm_ctx = hubbub2_init_vm_ctx,
.dcc_support_swizzle = hubbub2_dcc_support_swizzle,
.dcc_support_pixel_format = hubbub2_dcc_support_pixel_format,
.get_dcc_compression_cap = hubbub2_get_dcc_compression_cap,
-- 
2.17.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 07/26] drm/amd/display: add REFCYC_PER_TRIP_TO_MEMORY programming

[Bhawanpreet Lakha]

it allows us to do urgent latency programming

Signed-off-by: Bhawanpreet Lakha 
---
 .../drm/amd/display/dc/dcn20/dcn20_resource.c | 16 
 .../drm/amd/display/dc/dcn21/dcn21_hubbub.c   | 39 +--
 .../drm/amd/display/dc/dcn21/dcn21_hubbub.h   | 17 
 .../gpu/drm/amd/display/dc/inc/hw/mem_input.h |  1 +
 4 files changed, 69 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c 
b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
index 9cc6797e3860..086d1bc0d0a5 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
@@ -2573,6 +2573,10 @@ void dcn20_calculate_wm(
context->bw_ctx.bw.dcn.watermarks.b.cstate_pstate.cstate_exit_ns = 
get_wm_stutter_exit(>bw_ctx.dml, pipes, pipe_cnt) * 1000;
context->bw_ctx.bw.dcn.watermarks.b.cstate_pstate.pstate_change_ns = 
get_wm_dram_clock_change(>bw_ctx.dml, pipes, pipe_cnt) * 1000;
context->bw_ctx.bw.dcn.watermarks.b.pte_meta_urgent_ns = 
get_wm_memory_trip(>bw_ctx.dml, pipes, pipe_cnt) * 1000;
+#if defined(CONFIG_DRM_AMD_DC_DCN2_1)
+   context->bw_ctx.bw.dcn.watermarks.b.frac_urg_bw_nom = 
get_fraction_of_urgent_bandwidth(>bw_ctx.dml, pipes, pipe_cnt) * 1000;
+   context->bw_ctx.bw.dcn.watermarks.b.frac_urg_bw_flip = 
get_fraction_of_urgent_bandwidth_imm_flip(>bw_ctx.dml, pipes, 
pipe_cnt) * 1000;
+#endif
 
if (vlevel < 2) {
pipes[0].clks_cfg.voltage = 2;
@@ -2584,6 +2588,10 @@ void dcn20_calculate_wm(
context->bw_ctx.bw.dcn.watermarks.c.cstate_pstate.cstate_exit_ns = 
get_wm_stutter_exit(>bw_ctx.dml, pipes, pipe_cnt) * 1000;
context->bw_ctx.bw.dcn.watermarks.c.cstate_pstate.pstate_change_ns = 
get_wm_dram_clock_change(>bw_ctx.dml, pipes, pipe_cnt) * 1000;
context->bw_ctx.bw.dcn.watermarks.c.pte_meta_urgent_ns = 
get_wm_memory_trip(>bw_ctx.dml, pipes, pipe_cnt) * 1000;
+#if defined(CONFIG_DRM_AMD_DC_DCN2_1)
+   context->bw_ctx.bw.dcn.watermarks.c.frac_urg_bw_nom = 
get_fraction_of_urgent_bandwidth(>bw_ctx.dml, pipes, pipe_cnt) * 1000;
+   context->bw_ctx.bw.dcn.watermarks.c.frac_urg_bw_flip = 
get_fraction_of_urgent_bandwidth_imm_flip(>bw_ctx.dml, pipes, 
pipe_cnt) * 1000;
+#endif
 
if (vlevel < 3) {
pipes[0].clks_cfg.voltage = 3;
@@ -2595,6 +2603,10 @@ void dcn20_calculate_wm(
context->bw_ctx.bw.dcn.watermarks.d.cstate_pstate.cstate_exit_ns = 
get_wm_stutter_exit(>bw_ctx.dml, pipes, pipe_cnt) * 1000;
context->bw_ctx.bw.dcn.watermarks.d.cstate_pstate.pstate_change_ns = 
get_wm_dram_clock_change(>bw_ctx.dml, pipes, pipe_cnt) * 1000;
context->bw_ctx.bw.dcn.watermarks.d.pte_meta_urgent_ns = 
get_wm_memory_trip(>bw_ctx.dml, pipes, pipe_cnt) * 1000;
+#if defined(CONFIG_DRM_AMD_DC_DCN2_1)
+   context->bw_ctx.bw.dcn.watermarks.d.frac_urg_bw_nom = 
get_fraction_of_urgent_bandwidth(>bw_ctx.dml, pipes, pipe_cnt) * 1000;
+   context->bw_ctx.bw.dcn.watermarks.d.frac_urg_bw_flip = 
get_fraction_of_urgent_bandwidth_imm_flip(>bw_ctx.dml, pipes, 
pipe_cnt) * 1000;
+#endif
 
pipes[0].clks_cfg.voltage = vlevel;
pipes[0].clks_cfg.dcfclk_mhz = 
context->bw_ctx.dml.soc.clock_limits[vlevel].dcfclk_mhz;
@@ -2604,6 +2616,10 @@ void dcn20_calculate_wm(
context->bw_ctx.bw.dcn.watermarks.a.cstate_pstate.cstate_exit_ns = 
get_wm_stutter_exit(>bw_ctx.dml, pipes, pipe_cnt) * 1000;
context->bw_ctx.bw.dcn.watermarks.a.cstate_pstate.pstate_change_ns = 
get_wm_dram_clock_change(>bw_ctx.dml, pipes, pipe_cnt) * 1000;
context->bw_ctx.bw.dcn.watermarks.a.pte_meta_urgent_ns = 
get_wm_memory_trip(>bw_ctx.dml, pipes, pipe_cnt) * 1000;
+#if defined(CONFIG_DRM_AMD_DC_DCN2_1)
+   context->bw_ctx.bw.dcn.watermarks.a.frac_urg_bw_nom = 
get_fraction_of_urgent_bandwidth(>bw_ctx.dml, pipes, pipe_cnt) * 1000;
+   context->bw_ctx.bw.dcn.watermarks.a.frac_urg_bw_flip = 
get_fraction_of_urgent_bandwidth_imm_flip(>bw_ctx.dml, pipes, 
pipe_cnt) * 1000;
+#endif
 }
 
 void dcn20_calculate_dlg_params(
diff --git a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hubbub.c 
b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hubbub.c
index d1266741763b..8e7e79f44272 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hubbub.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hubbub.c
@@ -97,7 +97,7 @@ void dcn21_dchvm_init(struct hubbub *hubbub)
REG_WAIT(DCHVM_RIOMMU_STAT0, HOSTVM_PREFETCH_DONE, 1, 5, 100);
 }
 
-static int hubbub21_init_dchub(struct hubbub *hubbub,
+int hubbub21_init_dchub(struct hubbub *hubbub,
struct dcn_hubbub_phys_addr_config *pa_config)
 {
struct dcn20_hubbub *hubbub1 = TO_DCN20_HUBBUB(hubbub);
@@ -120,7 +120,7 @@ static int hubbub21_init_dchub(struct hubbub *hubbub,
return NUM_VMID;
 }
 
-static void hubbub21_program_urgent_watermarks(
+void hubbub21_program_urgent_watermarks(
struct hubbub *hubbub,
struct 

[PATCH 13/26] drm/amd/display: use dcn10 version of program tiling on Renoir

[Bhawanpreet Lakha]

From: Eric Yang 

[Why]
Renoir is gfx9, same as dcn10, not dcn20.

Signed-off-by: Eric Yang 
Acked-by: Bhawanpreet Lakha 
---
 drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hubp.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hubp.c 
b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hubp.c
index a00af513aa2b..2f5a5867e674 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hubp.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hubp.c
@@ -22,6 +22,8 @@
  * Authors: AMD
  *
  */
+
+#include "dcn10/dcn10_hubp.h"
 #include "dcn21_hubp.h"
 
 #include "dm_services.h"
@@ -202,7 +204,7 @@ static struct hubp_funcs dcn21_hubp_funcs = {
.hubp_enable_tripleBuffer = hubp2_enable_triplebuffer,
.hubp_is_triplebuffer_enabled = hubp2_is_triplebuffer_enabled,
.hubp_program_surface_flip_and_addr = 
hubp2_program_surface_flip_and_addr,
-   .hubp_program_surface_config = hubp2_program_surface_config,
+   .hubp_program_surface_config = hubp1_program_surface_config,
.hubp_is_flip_pending = hubp1_is_flip_pending,
.hubp_setup = hubp21_setup,
.hubp_setup_interdependent = hubp2_setup_interdependent,
-- 
2.17.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 04/26] drm/amd/display: Add DCN_BASE regs

[Bhawanpreet Lakha]

Signed-off-by: Bhawanpreet Lakha 
---
 .../gpu/drm/amd/include/renoir_ip_offset.h| 34 +++
 1 file changed, 34 insertions(+)

diff --git a/drivers/gpu/drm/amd/include/renoir_ip_offset.h 
b/drivers/gpu/drm/amd/include/renoir_ip_offset.h
index 094648cac392..07633e22e99a 100644
--- a/drivers/gpu/drm/amd/include/renoir_ip_offset.h
+++ b/drivers/gpu/drm/amd/include/renoir_ip_offset.h
@@ -169,6 +169,11 @@ static const struct IP_BASE NBIF0_BASE ={ { { { 
0x, 0x0014, 0x0D
 { { 0, 0, 0, 0, 0 } },
 { { 0, 0, 0, 0, 0 } },
 { { 0, 0, 0, 0, 0 } } } };
+static const struct IP_BASE DCN_BASE   ={ { { { 0x0012, 0x00C0, 
0x34C0, 0, 0 } },
+{ { 0, 0, 0, 0, 0 } },
+{ { 0, 0, 0, 0, 0 } },
+{ { 0, 0, 0, 0, 0 } },
+{ { 0, 0, 0, 0, 0 } } } };
 static const struct IP_BASE OSSSYS_BASE ={ { { { 0x10A0, 0x0240A000, 0, 0, 
0 } },
 { { 0, 0, 0, 0, 0 } },
 { { 0, 0, 0, 0, 0 } },
@@ -1361,4 +1366,33 @@ static const struct IP_BASE UVD0_BASE ={ { { { 
0x7800, 0x7E00, 0x0240300
 #define UVD0_BASE__INST6_SEG3  0
 #define UVD0_BASE__INST6_SEG4  0
 
+#define DCN_BASE__INST0_SEG0  0x0012
+#define DCN_BASE__INST0_SEG1  0x00C0
+#define DCN_BASE__INST0_SEG2  0x34C0
+#define DCN_BASE__INST0_SEG3  0
+#define DCN_BASE__INST0_SEG4  0
+
+#define DCN_BASE__INST1_SEG0  0
+#define DCN_BASE__INST1_SEG1  0
+#define DCN_BASE__INST1_SEG2  0
+#define DCN_BASE__INST1_SEG3  0
+#define DCN_BASE__INST1_SEG4  0
+
+#define DCN_BASE__INST2_SEG0  0
+#define DCN_BASE__INST2_SEG1  0
+#define DCN_BASE__INST2_SEG2  0
+#define DCN_BASE__INST2_SEG3  0
+#define DCN_BASE__INST2_SEG4  0
+
+#define DCN_BASE__INST3_SEG0  0
+#define DCN_BASE__INST3_SEG1  0
+#define DCN_BASE__INST3_SEG2  0
+#define DCN_BASE__INST3_SEG3  0
+#define DCN_BASE__INST3_SEG4  0
+
+#define DCN_BASE__INST4_SEG0  0
+#define DCN_BASE__INST4_SEG1  0
+#define DCN_BASE__INST4_SEG2  0
+#define DCN_BASE__INST4_SEG3  0
+#define DCN_BASE__INST4_SEG4  0
 #endif
-- 
2.17.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 01/26] drm/amd/display: update register field access mechanism

[Bhawanpreet Lakha]

From: abdoulaye berthe 

1-add timeout length and multiplier fields to aux_control1 register
2-update access mechanism from macro constructed name to uint32_t
defined addresses.
3-define registers and field per asic family

Signed-off-by: abdoulaye berthe 
Acked-by: Bhawanpreet Lakha 
---
 drivers/gpu/drm/amd/display/dc/dce/dce_aux.c  |  11 +-
 drivers/gpu/drm/amd/display/dc/dce/dce_aux.h  | 175 +-
 .../amd/display/dc/dce100/dce100_resource.c   |  12 +-
 .../amd/display/dc/dce110/dce110_resource.c   |  12 +-
 .../amd/display/dc/dce112/dce112_resource.c   |  12 +-
 .../amd/display/dc/dce120/dce120_resource.c   |  12 +-
 .../drm/amd/display/dc/dce80/dce80_resource.c |  12 +-
 .../drm/amd/display/dc/dcn10/dcn10_resource.c |  12 +-
 .../drm/amd/display/dc/dcn20/dcn20_resource.c |  13 +-
 .../drm/amd/display/dc/dcn21/dcn21_resource.c |  12 +-
 10 files changed, 271 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_aux.c 
b/drivers/gpu/drm/amd/display/dc/dce/dce_aux.c
index 48a0e4ae80c2..de233270e3d5 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dce_aux.c
+++ b/drivers/gpu/drm/amd/display/dc/dce/dce_aux.c
@@ -42,6 +42,10 @@
 
 #include "reg_helper.h"
 
+#undef FN
+#define FN(reg_name, field_name) \
+   aux110->shift->field_name, aux110->mask->field_name
+
 #define FROM_AUX_ENGINE(ptr) \
container_of((ptr), struct aux_engine_dce110, base)
 
@@ -414,11 +418,14 @@ void dce110_engine_destroy(struct dce_aux **engine)
*engine = NULL;
 
 }
+
 struct dce_aux *dce110_aux_engine_construct(struct aux_engine_dce110 
*aux_engine110,
struct dc_context *ctx,
uint32_t inst,
uint32_t timeout_period,
-   const struct dce110_aux_registers *regs)
+   const struct dce110_aux_registers *regs,
+   const struct dce110_aux_registers_mask *mask,
+   const struct dce110_aux_registers_shift *shift)
 {
aux_engine110->base.ddc = NULL;
aux_engine110->base.ctx = ctx;
@@ -428,6 +435,8 @@ struct dce_aux *dce110_aux_engine_construct(struct 
aux_engine_dce110 *aux_engine
aux_engine110->timeout_period = timeout_period;
aux_engine110->regs = regs;
 
+   aux_engine110->mask = mask;
+   aux_engine110->shift = shift;
return _engine110->base;
 }
 
diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_aux.h 
b/drivers/gpu/drm/amd/display/dc/dce/dce_aux.h
index ed7fec8fe253..717378502e9d 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dce_aux.h
+++ b/drivers/gpu/drm/amd/display/dc/dce/dce_aux.h
@@ -29,6 +29,7 @@
 #include "i2caux_interface.h"
 #include "inc/hw/aux_engine.h"
 
+
 #ifdef CONFIG_DRM_AMD_DC_DCN2_0
 #define AUX_COMMON_REG_LIST0(id)\
SRI(AUX_CONTROL, DP_AUX, id), \
@@ -36,6 +37,7 @@
SRI(AUX_SW_DATA, DP_AUX, id), \
SRI(AUX_SW_CONTROL, DP_AUX, id), \
SRI(AUX_INTERRUPT_CONTROL, DP_AUX, id), \
+   SRI(AUX_DPHY_RX_CONTROL1, DP_AUX, id), \
SRI(AUX_SW_STATUS, DP_AUX, id)
 #endif
 
@@ -55,6 +57,7 @@ struct dce110_aux_registers {
uint32_t AUX_SW_DATA;
uint32_t AUX_SW_CONTROL;
uint32_t AUX_INTERRUPT_CONTROL;
+   uint32_t AUX_DPHY_RX_CONTROL1;
uint32_t AUX_SW_STATUS;
uint32_t AUXN_IMPCAL;
uint32_t AUXP_IMPCAL;
@@ -62,6 +65,156 @@ struct dce110_aux_registers {
uint32_t AUX_RESET_MASK;
 };
 
+#define DCE_AUX_REG_FIELD_LIST(type)\
+   type AUX_EN;\
+   type AUX_RESET;\
+   type AUX_RESET_DONE;\
+   type AUX_REG_RW_CNTL_STATUS;\
+   type AUX_SW_USE_AUX_REG_REQ;\
+   type AUX_SW_DONE_USING_AUX_REG;\
+   type AUX_SW_AUTOINCREMENT_DISABLE;\
+   type AUX_SW_DATA_RW;\
+   type AUX_SW_INDEX;\
+   type AUX_SW_GO;\
+   type AUX_SW_DATA;\
+   type AUX_SW_REPLY_BYTE_COUNT;\
+   type AUX_SW_DONE;\
+   type AUX_SW_DONE_ACK;\
+   type AUXN_IMPCAL_ENABLE;\
+   type AUXP_IMPCAL_ENABLE;\
+   type AUXN_IMPCAL_OVERRIDE_ENABLE;\
+   type AUXP_IMPCAL_OVERRIDE_ENABLE;\
+   type AUX_RX_TIMEOUT_LEN;\
+   type AUX_RX_TIMEOUT_LEN_MUL;\
+   type AUXN_CALOUT_ERROR_AK;\
+   type AUXP_CALOUT_ERROR_AK;\
+   type AUX_SW_START_DELAY;\
+   type AUX_SW_WR_BYTES
+
+#define DCE10_AUX_MASK_SH_LIST(mask_sh)\
+   AUX_SF(AUX_CONTROL, AUX_EN, mask_sh),\
+   AUX_SF(AUX_ARB_CONTROL, AUX_REG_RW_CNTL_STATUS, mask_sh),\
+   AUX_SF(AUX_ARB_CONTROL, AUX_SW_USE_AUX_REG_REQ, mask_sh),\
+   AUX_SF(AUX_ARB_CONTROL, AUX_SW_DONE_USING_AUX_REG, mask_sh),\
+   AUX_SF(AUX_SW_CONTROL, AUX_SW_START_DELAY, mask_sh),\
+   AUX_SF(AUX_SW_CONTROL, AUX_SW_WR_BYTES, mask_sh),\
+   AUX_SF(AUX_SW_CONTROL, AUX_SW_GO, mask_sh),\
+   AUX_SF(AUX_SW_DATA, AUX_SW_AUTOINCREMENT_DISABLE, mask_sh),\
+   AUX_SF(AUX_SW_DATA, AUX_SW_DATA_RW, mask_sh),\
+   AUX_SF(AUX_SW_DATA, AUX_SW_AUTOINCREMENT_DISABLE, mask_sh),\
+   AUX_SF(AUX_SW_DATA, AUX_SW_INDEX, mask_sh),\
+   

[PATCH 17/26] drm/amd/display: update renoir bounding box and res_caps

[Bhawanpreet Lakha]

The values for bounding box and res_caps were incorrect. So
Fix them

Signed-off-by: Bhawanpreet Lakha 
---
 .../drm/amd/display/dc/dcn21/dcn21_resource.c | 24 ++-
 1 file changed, 13 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c 
b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
index 5e15f800a9f1..002e7fb67068 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
@@ -82,6 +82,7 @@
 
 
 struct _vcs_dpi_ip_params_st dcn2_1_ip = {
+   .odm_capable = 1,
.gpuvm_enable = 0,
.hostvm_enable = 0,
.gpuvm_max_page_table_levels = 1,
@@ -203,11 +204,11 @@ struct _vcs_dpi_soc_bounding_box_st dcn2_1_soc = {
.state = 4,
.dcfclk_mhz = 810.0,
.fabricclk_mhz = 1600.0,
-   .dispclk_mhz = 1015.0,
-   .dppclk_mhz = 1015.0,
-   .phyclk_mhz = 810.0,
+   .dispclk_mhz = 1395.0,
+   .dppclk_mhz = 1285.0,
+   .phyclk_mhz = 1325.0,
.socclk_mhz = 953.0,
-   .dscclk_mhz = 318.334,
+   .dscclk_mhz = 489.0,
.dram_speed_mts = 4266.0,
},
/*Extra state, no dispclk ramping*/
@@ -215,18 +216,18 @@ struct _vcs_dpi_soc_bounding_box_st dcn2_1_soc = {
.state = 5,
.dcfclk_mhz = 810.0,
.fabricclk_mhz = 1600.0,
-   .dispclk_mhz = 1015.0,
-   .dppclk_mhz = 1015.0,
-   .phyclk_mhz = 810.0,
+   .dispclk_mhz = 1395.0,
+   .dppclk_mhz = 1285.0,
+   .phyclk_mhz = 1325.0,
.socclk_mhz = 953.0,
-   .dscclk_mhz = 318.334,
+   .dscclk_mhz = 489.0,
.dram_speed_mts = 4266.0,
},
 
},
 
-   .sr_exit_time_us = 9.0,
-   .sr_enter_plus_exit_time_us = 11.0,
+   .sr_exit_time_us = 12.5,
+   .sr_enter_plus_exit_time_us = 17.0,
.urgent_latency_us = 4.0,
.urgent_latency_pixel_data_only_us = 4.0,
.urgent_latency_pixel_mixed_with_vm_data_us = 4.0,
@@ -764,6 +765,7 @@ static const struct resource_caps res_cap_rn = {
.num_pll = 5,  // maybe 3 because the last two used for USB-c
.num_dwb = 1,
.num_ddc = 5,
+   .num_vmid = 1,
 #ifdef CONFIG_DRM_AMD_DC_DSC_SUPPORT
.num_dsc = 3,
 #endif
@@ -833,7 +835,7 @@ static const struct dc_debug_options debug_defaults_drv = {
.disable_dcc = DCC_ENABLE,
.vsr_support = true,
.performance_trace = false,
-   .max_downscale_src_width = 5120,/*upto 5K*/
+   .max_downscale_src_width = 3840,
.disable_pplib_wm_range = false,
.scl_reset_length10 = true,
.sanity_checks = true,
-- 
2.17.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 03/26] drm/amd/display: Add DP_DPHY_INTERNAL_CTR regs

[Bhawanpreet Lakha]

Signed-off-by: Bhawanpreet Lakha 
---
 .../drm/amd/include/asic_reg/dcn/dcn_2_1_0_offset.h| 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/amd/include/asic_reg/dcn/dcn_2_1_0_offset.h 
b/drivers/gpu/drm/amd/include/asic_reg/dcn/dcn_2_1_0_offset.h
index be4249adb356..eddf83ec1c39 100644
--- a/drivers/gpu/drm/amd/include/asic_reg/dcn/dcn_2_1_0_offset.h
+++ b/drivers/gpu/drm/amd/include/asic_reg/dcn/dcn_2_1_0_offset.h
@@ -9859,6 +9859,8 @@
 #define mmDP0_DP_STEER_FIFO_BASE_IDX   
2
 #define mmDP0_DP_MSA_MISC  
0x210e
 #define mmDP0_DP_MSA_MISC_BASE_IDX 
2
+#define mmDP0_DP_DPHY_INTERNAL_CTRL
0x210f
+#define mmDP0_DP_DPHY_INTERNAL_CTRL_BASE_IDX   
2
 #define mmDP0_DP_VID_TIMING
0x2110
 #define mmDP0_DP_VID_TIMING_BASE_IDX   
2
 #define mmDP0_DP_VID_N 
0x2111
@@ -10187,6 +10189,8 @@
 #define mmDP1_DP_STEER_FIFO_BASE_IDX   
2
 #define mmDP1_DP_MSA_MISC  
0x220e
 #define mmDP1_DP_MSA_MISC_BASE_IDX 
2
+#define mmDP1_DP_DPHY_INTERNAL_CTRL
0x220f
+#define mmDP1_DP_DPHY_INTERNAL_CTRL_BASE_IDX   
2
 #define mmDP1_DP_VID_TIMING
0x2210
 #define mmDP1_DP_VID_TIMING_BASE_IDX   
2
 #define mmDP1_DP_VID_N 
0x2211
@@ -10515,6 +10519,8 @@
 #define mmDP2_DP_STEER_FIFO_BASE_IDX   
2
 #define mmDP2_DP_MSA_MISC  
0x230e
 #define mmDP2_DP_MSA_MISC_BASE_IDX 
2
+#define mmDP2_DP_DPHY_INTERNAL_CTRL
0x230f
+#define mmDP2_DP_DPHY_INTERNAL_CTRL_BASE_IDX   
2
 #define mmDP2_DP_VID_TIMING
0x2310
 #define mmDP2_DP_VID_TIMING_BASE_IDX   
2
 #define mmDP2_DP_VID_N 
0x2311
@@ -10843,6 +10849,8 @@
 #define mmDP3_DP_STEER_FIFO_BASE_IDX   
2
 #define mmDP3_DP_MSA_MISC  
0x240e
 #define mmDP3_DP_MSA_MISC_BASE_IDX 
2
+#define mmDP3_DP_DPHY_INTERNAL_CTRL
0x240f
+#define mmDP3_DP_DPHY_INTERNAL_CTRL_BASE_IDX   
2
 #define mmDP3_DP_VID_TIMING
0x2410
 #define mmDP3_DP_VID_TIMING_BASE_IDX   
2
 #define mmDP3_DP_VID_N 
0x2411
@@ -11171,6 +11179,8 @@
 #define mmDP4_DP_STEER_FIFO_BASE_IDX   
2
 #define mmDP4_DP_MSA_MISC  
0x250e
 #define mmDP4_DP_MSA_MISC_BASE_IDX 
2
+#define mmDP4_DP_DPHY_INTERNAL_CTRL
0x250f
+#define mmDP4_DP_DPHY_INTERNAL_CTRL_BASE_IDX   
2
 #define mmDP4_DP_VID_TIMING
0x2510
 #define mmDP4_DP_VID_TIMING_BASE_IDX   
2
 #define mmDP4_DP_VID_N 
0x2511
-- 
2.17.1

[PATCH 06/26] drm/amd/display: create dcn21_link_encoder files

[Bhawanpreet Lakha]

[Why]
DCN20 and DCN21 have different phy programming sequences.

[How]
Create a separate dcn21_link_encoder for Renoir

Signed-off-by: Bhawanpreet Lakha 
---
 .../amd/display/dc/dcn10/dcn10_link_encoder.h |  35 +-
 .../amd/display/dc/dcn20/dcn20_link_encoder.h |   7 +
 drivers/gpu/drm/amd/display/dc/dcn21/Makefile |   2 +-
 .../amd/display/dc/dcn21/dcn21_link_encoder.c | 384 ++
 .../amd/display/dc/dcn21/dcn21_link_encoder.h |  51 +++
 .../drm/amd/display/dc/dcn21/dcn21_resource.c |  85 +++-
 6 files changed, 560 insertions(+), 4 deletions(-)
 create mode 100644 drivers/gpu/drm/amd/display/dc/dcn21/dcn21_link_encoder.c
 create mode 100644 drivers/gpu/drm/amd/display/dc/dcn21/dcn21_link_encoder.h

diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_link_encoder.h 
b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_link_encoder.h
index 0c12395cfa36..239a6c90ffb9 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_link_encoder.h
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_link_encoder.h
@@ -250,6 +250,10 @@ struct dcn10_link_enc_registers {
type RDPCS_EXT_REFCLK_EN;\
type RDPCS_TX_FIFO_EN;\
type UNIPHY_LINK_ENABLE;\
+   type UNIPHY_CHANNEL0_XBAR_SOURCE;\
+   type UNIPHY_CHANNEL1_XBAR_SOURCE;\
+   type UNIPHY_CHANNEL2_XBAR_SOURCE;\
+   type UNIPHY_CHANNEL3_XBAR_SOURCE;\
type UNIPHY_CHANNEL0_INVERT;\
type UNIPHY_CHANNEL1_INVERT;\
type UNIPHY_CHANNEL2_INVERT;\
@@ -342,12 +346,41 @@ struct dcn10_link_enc_registers {
type RDPCS_PHY_DPALT_DISABLE_ACK;\
type RDPCS_PHY_DP_MPLLB_V2I;\
type RDPCS_PHY_DP_MPLLB_FREQ_VCO;\
+   type RDPCS_PHY_DP_MPLLB_CP_INT_GS;\
+   type RDPCS_PHY_RX_VREF_CTRL;\
type RDPCS_PHY_DP_MPLLB_CP_INT;\
type RDPCS_PHY_DP_MPLLB_CP_PROP;\
type RDPCS_PHY_RX_REF_LD_VAL;\
type RDPCS_PHY_RX_VCO_LD_VAL;\
type DPCSTX_DEBUG_CONFIG; \
-   type RDPCSTX_DEBUG_CONFIG
+   type RDPCSTX_DEBUG_CONFIG; \
+   type RDPCS_PHY_DP_TX0_EQ_MAIN;\
+   type RDPCS_PHY_DP_TX0_EQ_PRE;\
+   type RDPCS_PHY_DP_TX0_EQ_POST;\
+   type RDPCS_PHY_DP_TX1_EQ_MAIN;\
+   type RDPCS_PHY_DP_TX1_EQ_PRE;\
+   type RDPCS_PHY_DP_TX1_EQ_POST;\
+   type RDPCS_PHY_DP_TX2_EQ_MAIN;\
+   type RDPCS_PHY_DP_MPLLB_CP_PROP_GS;\
+   type RDPCS_PHY_DP_TX2_EQ_PRE;\
+   type RDPCS_PHY_DP_TX2_EQ_POST;\
+   type RDPCS_PHY_DP_TX3_EQ_MAIN;\
+   type RDPCS_PHY_DCO_RANGE;\
+   type RDPCS_PHY_DCO_FINETUNE;\
+   type RDPCS_PHY_DP_TX3_EQ_PRE;\
+   type RDPCS_PHY_DP_TX3_EQ_POST;\
+   type RDPCS_PHY_SUP_PRE_HP;\
+   type RDPCS_PHY_DP_TX0_VREGDRV_BYP;\
+   type RDPCS_PHY_DP_TX1_VREGDRV_BYP;\
+   type RDPCS_PHY_DP_TX2_VREGDRV_BYP;\
+   type RDPCS_PHY_DP_TX3_VREGDRV_BYP;\
+   type RDPCS_DMCU_DPALT_DIS_BLOCK_REG;\
+   type UNIPHYA_SOFT_RESET;\
+   type UNIPHYB_SOFT_RESET;\
+   type UNIPHYC_SOFT_RESET;\
+   type UNIPHYD_SOFT_RESET;\
+   type UNIPHYE_SOFT_RESET;\
+   type UNIPHYF_SOFT_RESET
 
 #define DCN20_LINK_ENCODER_REG_FIELD_LIST(type) \
type DIG_LANE0EN;\
diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_link_encoder.h 
b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_link_encoder.h
index 3736b5548a25..0c98a0bbbd14 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_link_encoder.h
+++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_link_encoder.h
@@ -91,6 +91,13 @@ struct mpll_cfg {
uint32_t ref_range;
uint32_t ref_clk;
bool hdmimode_enable;
+   bool sup_pre_hp;
+   bool dp_tx0_vergdrv_byp;
+   bool dp_tx1_vergdrv_byp;
+   bool dp_tx2_vergdrv_byp;
+   bool dp_tx3_vergdrv_byp;
+
+
 };
 
 struct dpcssys_phy_seq_cfg {
diff --git a/drivers/gpu/drm/amd/display/dc/dcn21/Makefile 
b/drivers/gpu/drm/amd/display/dc/dcn21/Makefile
index 5b8f42ae2334..b7a9285348fb 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn21/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dcn21/Makefile
@@ -1,7 +1,7 @@
 #
 # Makefile for DCN21.
 
-DCN21 = dcn21_hubp.o dcn21_hubbub.o dcn21_resource.o dcn21_hwseq.o
+DCN21 = dcn21_hubp.o dcn21_hubbub.o dcn21_resource.o dcn21_hwseq.o 
dcn21_link_encoder.o
 
 CFLAGS_dcn21_resource.o := -mhard-float -msse -mpreferred-stack-boundary=4
 
diff --git a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_link_encoder.c 
b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_link_encoder.c
new file mode 100644
index ..b835f5fcbe52
--- /dev/null
+++ b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_link_encoder.c
@@ -0,0 +1,384 @@
+/*
+ * Copyright 2012-15 Advanced Micro 

[PATCH 18/26] drm/amd/display: change PP_SM defs to 8

[Bhawanpreet Lakha]

DPM level is 8 these were incorrect before. Fix them

Signed-off-by: Bhawanpreet Lakha 
---
 drivers/gpu/drm/amd/display/dc/dm_pp_smu.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dm_pp_smu.h 
b/drivers/gpu/drm/amd/display/dc/dm_pp_smu.h
index c03a441ee638..de3c83c8f6c3 100644
--- a/drivers/gpu/drm/amd/display/dc/dm_pp_smu.h
+++ b/drivers/gpu/drm/amd/display/dc/dm_pp_smu.h
@@ -252,9 +252,9 @@ struct pp_smu_funcs_nv {
 #if defined(CONFIG_DRM_AMD_DC_DCN2_1)
 
 #define PP_SMU_NUM_SOCCLK_DPM_LEVELS  8
-#define PP_SMU_NUM_DCFCLK_DPM_LEVELS  4
-#define PP_SMU_NUM_FCLK_DPM_LEVELS4
-#define PP_SMU_NUM_MEMCLK_DPM_LEVELS  4
+#define PP_SMU_NUM_DCFCLK_DPM_LEVELS  8
+#define PP_SMU_NUM_FCLK_DPM_LEVELS8
+#define PP_SMU_NUM_MEMCLK_DPM_LEVELS  8
 
 struct dpm_clock {
   uint32_t  Freq;// In MHz
-- 
2.17.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 22/26] drm/amd/display: Fix rn audio playback and video playback speed

[Bhawanpreet Lakha]

From: Michael Strauss 

[WHY]
dprefclk is improperly read due to incorrect units used.
Causes an audio clock to be improperly set, making audio
non-functional and videos play back too fast

[HOW]
Scale dprefclk value from MHz to KHz (multiply by 1000)
to ensure that dprefclk_khz is in correct units

Signed-off-by: Michael Strauss 
Acked-by: Bhawanpreet Lakha 
---
 .../drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c | 15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c 
b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c
index 93e46e376bb1..fb8aa9436bf0 100644
--- a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c
+++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c
@@ -377,7 +377,7 @@ void rn_get_clk_states(struct clk_mgr *clk_mgr_base, struct 
clk_states *s)
 
rn_dump_clk_registers(, clk_mgr_base, _info);
 
-   s->dprefclk_khz = sb.dprefclk;
+   s->dprefclk_khz = sb.dprefclk * 1000;
 }
 
 void rn_enable_pme_wa(struct clk_mgr *clk_mgr_base)
@@ -633,16 +633,15 @@ void rn_clk_mgr_construct(
clk_mgr->dentist_vco_freq_khz = 360;
 
rn_dump_clk_registers(, _mgr->base, _info);
-   clk_mgr->base.dprefclk_khz = s.dprefclk;
-
-   if (clk_mgr->base.dprefclk_khz != 60) {
-   clk_mgr->base.dprefclk_khz = 60;
-   ASSERT(1); //TODO: Renoir follow up.
-   }
+   /* Convert dprefclk units from MHz to KHz */
+   /* Value already divided by 10, some resolution lost */
+   clk_mgr->base.dprefclk_khz = s.dprefclk * 1000;
 
/* in case we don't get a value from the register, use default 
*/
-   if (clk_mgr->base.dprefclk_khz == 0)
+   if (clk_mgr->base.dprefclk_khz == 0) {
+   ASSERT(clk_mgr->base.dprefclk_khz == 60);
clk_mgr->base.dprefclk_khz = 60;
+   }
}
 
dce_clock_read_ss_info(clk_mgr);
-- 
2.17.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 25/26] drm/amd/display: enable smu set dcfclk

[Bhawanpreet Lakha]

From: Lewis Huang 

[Why]
SMU fixed this issue after version 0x370c00

[How]
enable smu send message to set dcfclk after smu version 0x370c00

Signed-off-by: Lewis Huang 
Acked-by: Bhawanpreet Lakha 
---
 .../drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr_vbios_smu.c   | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git 
a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr_vbios_smu.c 
b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr_vbios_smu.c
index db28e91adb3d..2650776acbc3 100644
--- a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr_vbios_smu.c
+++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr_vbios_smu.c
@@ -124,7 +124,7 @@ int rn_vbios_smu_set_hard_min_dcfclk(struct 
clk_mgr_internal *clk_mgr, int reque
 {
int actual_dcfclk_set_mhz = -1;
 
-   if (clk_mgr->smu_ver < 0x)
+   if (clk_mgr->smu_ver < 0x370c00)
return actual_dcfclk_set_mhz;
 
actual_dcfclk_set_mhz = rn_vbios_smu_send_msg_with_param(
@@ -139,7 +139,7 @@ int rn_vbios_smu_set_min_deep_sleep_dcfclk(struct 
clk_mgr_internal *clk_mgr, int
 {
int actual_min_ds_dcfclk_mhz = -1;
 
-   if (clk_mgr->smu_ver < 0x)
+   if (clk_mgr->smu_ver < 0x370c00)
return actual_min_ds_dcfclk_mhz;
 
actual_min_ds_dcfclk_mhz = rn_vbios_smu_send_msg_with_param(
-- 
2.17.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 21/26] drm/amd/display: handle "18" case in TruncToValidBPP

[Bhawanpreet Lakha]

Handle 18 DecimalBPP like other cases

Signed-off-by: Bhawanpreet Lakha 
Acked-by: Bhawanpreet Lakha 
---
 drivers/gpu/drm/amd/display/dc/dml/dcn21/display_mode_vba_21.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn21/display_mode_vba_21.c 
b/drivers/gpu/drm/amd/display/dc/dml/dcn21/display_mode_vba_21.c
index fd707e7459b5..ba77957aefe3 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn21/display_mode_vba_21.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn21/display_mode_vba_21.c
@@ -3380,6 +3380,8 @@ static unsigned int TruncToValidBPP(
return 30;
else if (DecimalBPP >= 24 && (DesiredBPP == 0 || 
DesiredBPP == 24))
return 24;
+   else if (DecimalBPP >= 18 && (DesiredBPP == 0 || 
DesiredBPP == 18))
+   return 18;
else
return BPP_INVALID;
}
-- 
2.17.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 19/26] drm/amd/display: add dummy functions to smu for Renoir Silicon Diags

[Bhawanpreet Lakha]

From: Sung Lee 

[Why]
Previously only dummy functions were added in Diags for FPGA.
On silicon, this would lead to a segmentation fault on silicon diags.

[How]
Check if diags silicon and if so, add dummy functions.

Signed-off-by: Sung Lee 
Acked-by: Bhawanpreet Lakha 
---
 drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c 
b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
index 002e7fb67068..25f62a3f2ffc 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
@@ -1397,7 +1397,7 @@ static struct pp_smu_funcs *dcn21_pp_smu_create(struct 
dc_context *ctx)
if (!pp_smu)
return pp_smu;
 
-   if (IS_FPGA_MAXIMUS_DC(ctx->dce_environment)) {
+   if (IS_FPGA_MAXIMUS_DC(ctx->dce_environment) || 
IS_DIAG_DC(ctx->dce_environment)) {
pp_smu->ctx.ver = PP_SMU_VER_RN;
pp_smu->rn_funcs.get_dpm_clock_table = 
dummy_get_dpm_clock_table;
pp_smu->rn_funcs.set_wm_ranges = dummy_set_wm_ranges;
-- 
2.17.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 10/26] drm/amd/display: fix incorrect page table address for renoir

[Bhawanpreet Lakha]

Incorrect page table address and programming sys aperture for
stutter gather, so fix it.

Signed-off-by: Bhawanpreet Lakha 
---
 .../drm/amd/display/dc/dcn21/dcn21_hubbub.c   | 23 ++-
 1 file changed, 17 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hubbub.c 
b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hubbub.c
index bd247e5e753e..fdfbdeb32459 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hubbub.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hubbub.c
@@ -111,19 +111,30 @@ int hubbub21_init_dchub(struct hubbub *hubbub,
struct dcn_hubbub_phys_addr_config *pa_config)
 {
struct dcn20_hubbub *hubbub1 = TO_DCN20_HUBBUB(hubbub);
+   struct dcn_vmid_page_table_config phys_config;
 
REG_SET(DCN_VM_FB_LOCATION_BASE, 0,
-   FB_BASE, pa_config->system_aperture.fb_base);
+   FB_BASE, pa_config->system_aperture.fb_base >> 24);
REG_SET(DCN_VM_FB_LOCATION_TOP, 0,
-   FB_TOP, pa_config->system_aperture.fb_top);
+   FB_TOP, pa_config->system_aperture.fb_top >> 24);
REG_SET(DCN_VM_FB_OFFSET, 0,
-   FB_OFFSET, pa_config->system_aperture.fb_offset);
+   FB_OFFSET, pa_config->system_aperture.fb_offset >> 24);
REG_SET(DCN_VM_AGP_BOT, 0,
-   AGP_BOT, pa_config->system_aperture.agp_bot);
+   AGP_BOT, pa_config->system_aperture.agp_bot >> 24);
REG_SET(DCN_VM_AGP_TOP, 0,
-   AGP_TOP, pa_config->system_aperture.agp_top);
+   AGP_TOP, pa_config->system_aperture.agp_top >> 24);
REG_SET(DCN_VM_AGP_BASE, 0,
-   AGP_BASE, pa_config->system_aperture.agp_base);
+   AGP_BASE, pa_config->system_aperture.agp_base >> 24);
+
+   if (pa_config->gart_config.page_table_start_addr != 
pa_config->gart_config.page_table_end_addr) {
+   phys_config.page_table_start_addr = 
pa_config->gart_config.page_table_start_addr >> 12;
+   phys_config.page_table_end_addr = 
pa_config->gart_config.page_table_end_addr >> 12;
+   phys_config.page_table_base_addr = 
pa_config->gart_config.page_table_base_addr | 1; //Note: hack
+   phys_config.depth = 0;
+   phys_config.block_size = 0;
+   // Init VMID 0 based on PA config
+   dcn20_vmid_setup(>vmid[0], _config);
+   }
 
dcn21_dchvm_init(hubbub);
 
-- 
2.17.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 02/26] drm/amd/display: configurable aux timeout support

[Bhawanpreet Lakha]

From: abdoulaye berthe 

[Description]
1-add configurable timeout support to aux engine.
2-add timeout support field to dc_caps
3-add reg_key to override extended timeout support

Signed-off-by: abdoulaye berthe 
Acked-by: Bhawanpreet Lakha 
---
 .../gpu/drm/amd/display/dc/core/dc_link_ddc.c | 14 
 drivers/gpu/drm/amd/display/dc/dc.h   |  2 +
 drivers/gpu/drm/amd/display/dc/dce/dce_aux.c  | 73 ++-
 drivers/gpu/drm/amd/display/dc/dce/dce_aux.h  | 16 +++-
 .../amd/display/dc/dce100/dce100_resource.c   |  5 +-
 .../amd/display/dc/dce110/dce110_resource.c   |  4 +-
 .../amd/display/dc/dce112/dce112_resource.c   |  5 +-
 .../amd/display/dc/dce120/dce120_resource.c   |  5 +-
 .../drm/amd/display/dc/dce80/dce80_resource.c |  4 +-
 .../drm/amd/display/dc/dcn10/dcn10_resource.c |  5 +-
 .../drm/amd/display/dc/dcn20/dcn20_resource.c |  4 +-
 .../drm/amd/display/dc/dcn21/dcn21_resource.c |  4 +-
 .../gpu/drm/amd/display/dc/inc/dc_link_ddc.h  |  3 +
 .../gpu/drm/amd/display/dc/inc/dc_link_dp.h   |  2 +
 .../drm/amd/display/dc/inc/hw/aux_engine.h|  3 +
 15 files changed, 132 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c
index 57fb0574f198..9a56f110bbd1 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c
@@ -634,6 +634,20 @@ bool dc_link_aux_transfer_with_retries(struct ddc_service 
*ddc,
return dce_aux_transfer_with_retries(ddc, payload);
 }
 
+
+enum dc_status dc_link_aux_configure_timeout(struct ddc_service *ddc,
+   uint32_t timeout)
+{
+   enum dc_status status = DC_OK;
+   struct ddc *ddc_pin = ddc->ddc_pin;
+
+   if 
(ddc->ctx->dc->res_pool->engines[ddc_pin->pin_data->en]->funcs->configure_timeout
 == NULL)
+   return DC_ERROR_UNEXPECTED;
+   if 
(!ddc->ctx->dc->res_pool->engines[ddc_pin->pin_data->en]->funcs->configure_timeout(ddc,
 timeout))
+   status = DC_ERROR_UNEXPECTED;
+   return status;
+}
+
 /*test only function*/
 void dal_ddc_service_set_ddc_pin(
struct ddc_service *ddc_service,
diff --git a/drivers/gpu/drm/amd/display/dc/dc.h 
b/drivers/gpu/drm/amd/display/dc/dc.h
index 41e366f59f10..5967106826ca 100644
--- a/drivers/gpu/drm/amd/display/dc/dc.h
+++ b/drivers/gpu/drm/amd/display/dc/dc.h
@@ -111,6 +111,7 @@ struct dc_caps {
bool force_dp_tps4_for_cp2520;
bool disable_dp_clk_share;
bool psp_setup_panel_mode;
+   bool extended_aux_timeout_support;
 #ifdef CONFIG_DRM_AMD_DC_DCN2_0
bool hw_3d_lut;
 #endif
@@ -220,6 +221,7 @@ struct dc_config {
bool power_down_display_on_boot;
bool edp_not_connected;
bool forced_clocks;
+   bool disable_extended_timeout_support; // Used to disable extended 
timeout and lttpr feature as well
bool multi_mon_pp_mclk_switch;
 };
 
diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_aux.c 
b/drivers/gpu/drm/amd/display/dc/dce/dce_aux.c
index de233270e3d5..976bd4987a28 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dce_aux.c
+++ b/drivers/gpu/drm/amd/display/dc/dce/dce_aux.c
@@ -59,6 +59,14 @@ enum {
AUX_TIMED_OUT_RETRY_COUNTER = 2,
AUX_DEFER_RETRY_COUNTER = 6
 };
+
+#define TIME_OUT_INCREMENT  1016
+#define TIME_OUT_MULTIPLIER_8  8
+#define TIME_OUT_MULTIPLIER_16  16
+#define TIME_OUT_MULTIPLIER_32  32
+#define TIME_OUT_MULTIPLIER_64  64
+#define MAX_TIMEOUT_LENGTH  127
+
 static void release_engine(
struct dce_aux *engine)
 {
@@ -202,7 +210,7 @@ static void submit_channel_request(
REG_UPDATE(AUX_INTERRUPT_CONTROL, AUX_SW_DONE_ACK, 1);
 
REG_WAIT(AUX_SW_STATUS, AUX_SW_DONE, 0,
-   10, aux110->timeout_period/10);
+   10, aux110->polling_timeout_period/10);
 
/* set the delay and the number of bytes to write */
 
@@ -331,7 +339,7 @@ static enum aux_channel_operation_result get_channel_status(
 
/* poll to make sure that SW_DONE is asserted */
REG_WAIT(AUX_SW_STATUS, AUX_SW_DONE, 1,
-   10, aux110->timeout_period/10);
+   10, aux110->polling_timeout_period/10);
 
value = REG_READ(AUX_SW_STATUS);
/* in case HPD is LOW, exit AUX transaction */
@@ -419,24 +427,81 @@ void dce110_engine_destroy(struct dce_aux **engine)
 
 }
 
+static bool dce_aux_configure_timeout(struct ddc_service *ddc,
+   uint32_t timeout_in_us)
+{
+   uint32_t multiplier = 0;
+   uint32_t length = 0;
+   uint32_t timeout = 0;
+   struct ddc *ddc_pin = ddc->ddc_pin;
+   struct dce_aux *aux_engine = 
ddc->ctx->dc->res_pool->engines[ddc_pin->pin_data->en];
+   struct aux_engine_dce110 *aux110 = FROM_AUX_ENGINE(aux_engine);
+
+   /* 1-Update polling timeout period */
+   aux110->polling_timeout_period = timeout_in_us * 

[PATCH 16/26] drm/amd/display: update dcn21 hubbub registers

[Bhawanpreet Lakha]

use dcn20 common regs define to share some regs with dcn20

Signed-off-by: Bhawanpreet Lakha 
---
 .../gpu/drm/amd/display/dc/dcn21/dcn21_hubbub.h | 17 +++--
 1 file changed, 7 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hubbub.h 
b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hubbub.h
index 698c470cc0f6..c4840dfb1fa5 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hubbub.h
+++ b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hubbub.h
@@ -36,6 +36,10 @@
SR(DCHUBBUB_ARB_FRAC_URG_BW_FLIP_B),\
SR(DCHUBBUB_ARB_FRAC_URG_BW_FLIP_C),\
SR(DCHUBBUB_ARB_FRAC_URG_BW_FLIP_D),\
+   SR(DCHUBBUB_ARB_REFCYC_PER_TRIP_TO_MEMORY_A),\
+   SR(DCHUBBUB_ARB_REFCYC_PER_TRIP_TO_MEMORY_B),\
+   SR(DCHUBBUB_ARB_REFCYC_PER_TRIP_TO_MEMORY_C),\
+   SR(DCHUBBUB_ARB_REFCYC_PER_TRIP_TO_MEMORY_D),\
SR(DCHUBBUB_ARB_HOSTVM_CNTL), \
SR(DCHVM_CTRL0), \
SR(DCHVM_MEM_CTRL), \
@@ -44,16 +48,9 @@
SR(DCHVM_RIOMMU_STAT0)
 
 #define HUBBUB_REG_LIST_DCN21()\
-   HUBBUB_REG_LIST_DCN_COMMON(), \
+   HUBBUB_REG_LIST_DCN20_COMMON(), \
HUBBUB_SR_WATERMARK_REG_LIST(), \
-   HUBBUB_HVM_REG_LIST(), \
-   SR(DCHUBBUB_CRC_CTRL), \
-   SR(DCN_VM_FB_LOCATION_BASE),\
-   SR(DCN_VM_FB_LOCATION_TOP),\
-   SR(DCN_VM_FB_OFFSET),\
-   SR(DCN_VM_AGP_BOT),\
-   SR(DCN_VM_AGP_TOP),\
-   SR(DCN_VM_AGP_BASE)
+   HUBBUB_HVM_REG_LIST()
 
 #define HUBBUB_MASK_SH_LIST_HVM(mask_sh) \
HUBBUB_SF(DCHUBBUB_ARB_DF_REQ_OUTSTAND, 
DCHUBBUB_ARB_MIN_REQ_OUTSTAND_COMMIT_THRESHOLD, mask_sh), \
@@ -102,7 +99,7 @@
HUBBUB_SF(DCHUBBUB_ARB_REFCYC_PER_TRIP_TO_MEMORY_D, 
DCHUBBUB_ARB_REFCYC_PER_TRIP_TO_MEMORY_D, mask_sh)
 
 #define HUBBUB_MASK_SH_LIST_DCN21(mask_sh)\
-   HUBBUB_MASK_SH_LIST_HVM(mask_sh),\
+   HUBBUB_MASK_SH_LIST_HVM(mask_sh), \
HUBBUB_MASK_SH_LIST_DCN_COMMON(mask_sh), \
HUBBUB_MASK_SH_LIST_STUTTER(mask_sh), \
HUBBUB_SF(DCHUBBUB_GLOBAL_TIMER_CNTL, DCHUBBUB_GLOBAL_TIMER_REFDIV, 
mask_sh), \
-- 
2.17.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 15/26] drm/amd/display: add detile buffer size for renoir

[Bhawanpreet Lakha]

Detile buffer size affects dcc caps, it was already added for
dcn2. Now add it for dcn21

Signed-off-by: Bhawanpreet Lakha 
---
 drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hubbub.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hubbub.c 
b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hubbub.c
index aeb5de6f4530..f546260c15b7 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hubbub.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hubbub.c
@@ -653,4 +653,5 @@ void hubbub21_construct(struct dcn20_hubbub *hubbub,
hubbub->masks = hubbub_mask;
 
hubbub->debug_test_index_pstate = 0xB;
+   hubbub->detile_buf_size = 164 * 1024; /* 164KB for DCN2.0 */
 }
-- 
2.17.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 26/26] drm/amd/display: use requested_dispclk_khz instead of clk

[Bhawanpreet Lakha]

Use requested_dispclk_khz / 1000 directly

Signed-off-by: Bhawanpreet Lakha 
---
 .../display/dc/clk_mgr/dcn21/rn_clk_mgr_vbios_smu.c | 13 ++---
 1 file changed, 2 insertions(+), 11 deletions(-)

diff --git 
a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr_vbios_smu.c 
b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr_vbios_smu.c
index 2650776acbc3..5647fcf10717 100644
--- a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr_vbios_smu.c
+++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr_vbios_smu.c
@@ -84,16 +84,12 @@ int rn_vbios_smu_set_dispclk(struct clk_mgr_internal 
*clk_mgr, int requested_dis
int actual_dispclk_set_mhz = -1;
struct dc *core_dc = clk_mgr->base.ctx->dc;
struct dmcu *dmcu = core_dc->res_pool->dmcu;
-   uint32_t clk = requested_dispclk_khz / 1000;
-
-   if (clk <= 100)
-   clk = 101;
 
/*  Unit of SMU msg parameter is Mhz */
actual_dispclk_set_mhz = rn_vbios_smu_send_msg_with_param(
clk_mgr,
VBIOSSMC_MSG_SetDispclkFreq,
-   clk);
+   requested_dispclk_khz / 1000);
 
if (!IS_FPGA_MAXIMUS_DC(core_dc->ctx->dce_environment)) {
if (dmcu && dmcu->funcs->is_dmcu_initialized(dmcu)) {
@@ -162,15 +158,10 @@ int rn_vbios_smu_set_dppclk(struct clk_mgr_internal 
*clk_mgr, int requested_dpp_
 {
int actual_dppclk_set_mhz = -1;
 
-   uint32_t clk = requested_dpp_khz / 1000;
-
-   if (clk <= 100)
-   clk = 101;
-
actual_dppclk_set_mhz = rn_vbios_smu_send_msg_with_param(
clk_mgr,
VBIOSSMC_MSG_SetDppclkFreq,
-   clk);
+   requested_dpp_khz / 1000);
 
return actual_dppclk_set_mhz * 1000;
 }
-- 
2.17.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 09/26] drm/amd/display: enable hostvm based on roimmu active for dcn2.1

[Bhawanpreet Lakha]

From: Dmytro Laktyushkin 

Enabling hostvm when ROIMMU is not active seems to break GPUVM.
This fixes the issue by not enabling hostvm if ROIMMU is not
activated.

Signed-off-by: Dmytro Laktyushkin 
Acked-by: Bhawanpreet Lakha 
---
 .../drm/amd/display/dc/dcn21/dcn21_hubbub.c   | 40 ---
 1 file changed, 25 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hubbub.c 
b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hubbub.c
index 8e7e79f44272..bd247e5e753e 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hubbub.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hubbub.c
@@ -22,6 +22,7 @@
  * Authors: AMD
  *
  */
+#include 
 #include "dm_services.h"
 #include "dcn20/dcn20_hubbub.h"
 #include "dcn21_hubbub.h"
@@ -71,30 +72,39 @@ static uint32_t convert_and_clamp(
 void dcn21_dchvm_init(struct hubbub *hubbub)
 {
struct dcn20_hubbub *hubbub1 = TO_DCN20_HUBBUB(hubbub);
+   uint32_t riommu_active;
+   int i;
 
//Init DCHVM block
REG_UPDATE(DCHVM_CTRL0, HOSTVM_INIT_REQ, 1);
 
//Poll until RIOMMU_ACTIVE = 1
-   //TODO: Figure out interval us and retry count
-   REG_WAIT(DCHVM_RIOMMU_STAT0, RIOMMU_ACTIVE, 1, 5, 100);
+   for (i = 0; i < 100; i++) {
+   REG_GET(DCHVM_RIOMMU_STAT0, RIOMMU_ACTIVE, _active);
 
-   //Reflect the power status of DCHUBBUB
-   REG_UPDATE(DCHVM_RIOMMU_CTRL0, HOSTVM_POWERSTATUS, 1);
+   if (riommu_active)
+   break;
+   else
+   udelay(5);
+   }
+
+   if (riommu_active) {
+   //Reflect the power status of DCHUBBUB
+   REG_UPDATE(DCHVM_RIOMMU_CTRL0, HOSTVM_POWERSTATUS, 1);
 
-   //Start rIOMMU prefetching
-   REG_UPDATE(DCHVM_RIOMMU_CTRL0, HOSTVM_PREFETCH_REQ, 1);
+   //Start rIOMMU prefetching
+   REG_UPDATE(DCHVM_RIOMMU_CTRL0, HOSTVM_PREFETCH_REQ, 1);
 
-   // Enable dynamic clock gating
-   REG_UPDATE_4(DCHVM_CLK_CTRL,
-   HVM_DISPCLK_R_GATE_DIS, 0,
-   HVM_DISPCLK_G_GATE_DIS, 0,
-   HVM_DCFCLK_R_GATE_DIS, 0,
-   HVM_DCFCLK_G_GATE_DIS, 0);
+   // Enable dynamic clock gating
+   REG_UPDATE_4(DCHVM_CLK_CTRL,
+   HVM_DISPCLK_R_GATE_DIS, 0,
+   HVM_DISPCLK_G_GATE_DIS, 0,
+   HVM_DCFCLK_R_GATE_DIS, 0,
+   HVM_DCFCLK_G_GATE_DIS, 0);
 
-   //Poll until HOSTVM_PREFETCH_DONE = 1
-   //TODO: Figure out interval us and retry count
-   REG_WAIT(DCHVM_RIOMMU_STAT0, HOSTVM_PREFETCH_DONE, 1, 5, 100);
+   //Poll until HOSTVM_PREFETCH_DONE = 1
+   REG_WAIT(DCHVM_RIOMMU_STAT0, HOSTVM_PREFETCH_DONE, 1, 5, 100);
+   }
 }
 
 int hubbub21_init_dchub(struct hubbub *hubbub,
-- 
2.17.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: drm/amd/display: Add HDCP module - static analysis bug report

[Daniel Vetter]

On Wed, Oct 9, 2019 at 10:46 PM Lakha, Bhawanpreet
 wrote:
>
> I misunderstood and was talking about the ksv validation specifically
> (usage of drm_hdcp_check_ksvs_revoked()).

Hm for that specifically I think you want to do both, i.e. both
consult your psp, but also check for revoked ksvs with the core
helper. At least on some platforms only the core helper might have the
updated revoke list.

> For the defines I will create patches to use drm_hdcp where it is usable.

Thanks a lot. Ime once we have shared definitions it's much easier to
also share some helpers, where it makes sense.

Aside I think the hdcp code could also use a bit of demidlayering. At
least I'm not understanding why you add a 2nd abstraction layer for
i2c/dpcd, dm_helper already has that. That seems like one abstraction
layer too much.
-Daniel

>
>
> Bhawan
>
> On 2019-10-09 2:43 p.m., Daniel Vetter wrote:
> > On Wed, Oct 9, 2019 at 8:23 PM Lakha, Bhawanpreet
> >  wrote:
> >> Hi,
> >>
> >> The reason we don't use drm_hdcp is because our policy is to do hdcp
> >> verification using PSP/HW (onboard secure processor).
> > i915 also uses hw to auth, we still use the parts from drm_hdcp ...
> > Did you actually look at what's in there? It's essentially just shared
> > defines and data structures from the standard, plus a few minimal
> > helpers to en/decode some bits. Just from a quick read the entire
> > patch very much looks like midlayer everywhere design that we
> > discussed back when DC landed ...
> > -Daniel
> >
> >> Bhawan
> >>
> >> On 2019-10-09 12:32 p.m., Daniel Vetter wrote:
> >>> On Thu, Oct 03, 2019 at 11:08:03PM +0100, Colin Ian King wrote:
>  Hi,
> 
>  Static analysis with Coverity has detected a potential issue with
>  function validate_bksv in
>  drivers/gpu/drm/amd/display/modules/hdcp/hdcp1_execution.c with recent
>  commit:
> 
>  commit ed9d8e2bcb003ec94658cafe9b1bb3960e2139ec
>  Author: Bhawanpreet Lakha 
>  Date:   Tue Aug 6 17:52:01 2019 -0400
> 
>    drm/amd/display: Add HDCP module
> >>> I think the real question here is ... why is this not using drm_hdcp?
> >>> -Daniel
> >>>
>  The analysis is as follows:
> 
> 28 static inline enum mod_hdcp_status validate_bksv(struct mod_hdcp 
>  *hdcp)
> 29 {
> 
>  CID 89852 (#1 of 1): Out-of-bounds read (OVERRUN)
> 
>  1. overrun-local:
>  Overrunning array of 5 bytes at byte offset 7 by dereferencing pointer
>  (uint64_t *)hdcp->auth.msg.hdcp1.bksv.
> 
> 30uint64_t n = *(uint64_t *)hdcp->auth.msg.hdcp1.bksv;
> 31uint8_t count = 0;
> 32
> 33while (n) {
> 34count++;
> 35n &= (n - 1);
> 36}
> 
>  hdcp->auth.msg.hdcp1.bksv is an array of 5 uint8_t as defined in
>  drivers/gpu/drm/amd/display/modules/hdcp/hdcp.h as follows:
> 
>  struct mod_hdcp_message_hdcp1 {
>    uint8_t an[8];
>    uint8_t aksv[5];
>    uint8_t ainfo;
>    uint8_t bksv[5];
>    uint16_tr0p;
>    uint8_t bcaps;
>    uint16_tbstatus;
>    uint8_t ksvlist[635];
>    uint16_tksvlist_size;
>    uint8_t vp[20];
> 
>    uint16_tbinfo_dp;
>  };
> 
>  variable n is going to contain the contains of r0p and bcaps. I'm not
>  sure if that is intentional. If not, then the count is going to be
>  incorrect if these are non-zero.
> 
>  Colin
> >> ___
> >> dri-devel mailing list
> >> dri-de...@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
> >



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: drm/amd/display: Add HDCP module - static analysis bug report

[Lakha, Bhawanpreet]

I misunderstood and was talking about the ksv validation specifically 
(usage of drm_hdcp_check_ksvs_revoked()).

For the defines I will create patches to use drm_hdcp where it is usable.


Bhawan

On 2019-10-09 2:43 p.m., Daniel Vetter wrote:
> On Wed, Oct 9, 2019 at 8:23 PM Lakha, Bhawanpreet
>  wrote:
>> Hi,
>>
>> The reason we don't use drm_hdcp is because our policy is to do hdcp
>> verification using PSP/HW (onboard secure processor).
> i915 also uses hw to auth, we still use the parts from drm_hdcp ...
> Did you actually look at what's in there? It's essentially just shared
> defines and data structures from the standard, plus a few minimal
> helpers to en/decode some bits. Just from a quick read the entire
> patch very much looks like midlayer everywhere design that we
> discussed back when DC landed ...
> -Daniel
>
>> Bhawan
>>
>> On 2019-10-09 12:32 p.m., Daniel Vetter wrote:
>>> On Thu, Oct 03, 2019 at 11:08:03PM +0100, Colin Ian King wrote:
 Hi,

 Static analysis with Coverity has detected a potential issue with
 function validate_bksv in
 drivers/gpu/drm/amd/display/modules/hdcp/hdcp1_execution.c with recent
 commit:

 commit ed9d8e2bcb003ec94658cafe9b1bb3960e2139ec
 Author: Bhawanpreet Lakha 
 Date:   Tue Aug 6 17:52:01 2019 -0400

   drm/amd/display: Add HDCP module
>>> I think the real question here is ... why is this not using drm_hdcp?
>>> -Daniel
>>>
 The analysis is as follows:

28 static inline enum mod_hdcp_status validate_bksv(struct mod_hdcp 
 *hdcp)
29 {

 CID 89852 (#1 of 1): Out-of-bounds read (OVERRUN)

 1. overrun-local:
 Overrunning array of 5 bytes at byte offset 7 by dereferencing pointer
 (uint64_t *)hdcp->auth.msg.hdcp1.bksv.

30uint64_t n = *(uint64_t *)hdcp->auth.msg.hdcp1.bksv;
31uint8_t count = 0;
32
33while (n) {
34count++;
35n &= (n - 1);
36}

 hdcp->auth.msg.hdcp1.bksv is an array of 5 uint8_t as defined in
 drivers/gpu/drm/amd/display/modules/hdcp/hdcp.h as follows:

 struct mod_hdcp_message_hdcp1 {
   uint8_t an[8];
   uint8_t aksv[5];
   uint8_t ainfo;
   uint8_t bksv[5];
   uint16_tr0p;
   uint8_t bcaps;
   uint16_tbstatus;
   uint8_t ksvlist[635];
   uint16_tksvlist_size;
   uint8_t vp[20];

   uint16_tbinfo_dp;
 };

 variable n is going to contain the contains of r0p and bcaps. I'm not
 sure if that is intentional. If not, then the count is going to be
 incorrect if these are non-zero.

 Colin
>> ___
>> dri-devel mailing list
>> dri-de...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v2 26/27] drm/dp_mst: Also print unhashed pointers for malloc/topology references

[Lyude Paul]

Hey! Re: our discussion about this at XDC, I think I'm going to drop this
patch and just fix KASAN so it prints the hashed pointer as well, I'll cc you
on the patches for that as well

On Fri, 2019-09-27 at 10:25 -0400, Sean Paul wrote:
> On Tue, Sep 03, 2019 at 04:46:04PM -0400, Lyude Paul wrote:
> > Currently we only print mstb/port pointer addresses in our malloc and
> > topology refcount functions using the hashed-by-default %p, but
> > unfortunately if you're trying to debug a use-after-free error caused by
> > a refcounting error then this really isn't terribly useful. On the other
> > hand though, everything in the rest of the DP MST helpers uses hashed
> > pointer values as well and probably isn't useful to convert to unhashed.
> > So, let's just get the best of both worlds and print both the hashed and
> > unhashed pointer in our malloc/topology refcount debugging output. This
> > will hopefully make it a lot easier to figure out which port/mstb is
> > causing KASAN to get upset.
> > 
> > Cc: Juston Li 
> > Cc: Imre Deak 
> > Cc: Ville Syrjälä 
> > Cc: Harry Wentland 
> > Cc: Daniel Vetter 
> > Signed-off-by: Lyude Paul 
> 
> It's really too bad there isn't a CONFIG_DEBUG_SHOW_PK_ADDRESSES or even a
> value
> of kptr_restrict value that bypasses pointer hashing. I'm sure we're not the
> only ones to feel this pain. Maybe everyone just hacks vsnprintf...
> 
> As it is, I'm not totally sold on exposing the actual addresses
> unconditionally.
> What do you think about pulling the print out into a function and only
> printing
> px if a debug kconfig is set?
> 
> Sean
> 
> > ---
> >  drivers/gpu/drm/drm_dp_mst_topology.c | 34 ---
> >  1 file changed, 20 insertions(+), 14 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > index 2fe24e366925..5b5c0b3b3c0e 100644
> > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > @@ -1327,7 +1327,8 @@ static void
> >  drm_dp_mst_get_mstb_malloc(struct drm_dp_mst_branch *mstb)
> >  {
> > kref_get(>malloc_kref);
> > -   DRM_DEBUG("mstb %p (%d)\n", mstb, kref_read(>malloc_kref));
> > +   DRM_DEBUG("mstb %p/%px (%d)\n",
> > + mstb, mstb, kref_read(>malloc_kref));
> >  }
> >  
> >  /**
> > @@ -1344,7 +1345,8 @@ drm_dp_mst_get_mstb_malloc(struct drm_dp_mst_branch
> > *mstb)
> >  static void
> >  drm_dp_mst_put_mstb_malloc(struct drm_dp_mst_branch *mstb)
> >  {
> > -   DRM_DEBUG("mstb %p (%d)\n", mstb, kref_read(>malloc_kref) - 1);
> > +   DRM_DEBUG("mstb %p/%px (%d)\n",
> > + mstb, mstb, kref_read(>malloc_kref) - 1);
> > kref_put(>malloc_kref, drm_dp_free_mst_branch_device);
> >  }
> >  
> > @@ -1379,7 +1381,8 @@ void
> >  drm_dp_mst_get_port_malloc(struct drm_dp_mst_port *port)
> >  {
> > kref_get(>malloc_kref);
> > -   DRM_DEBUG("port %p (%d)\n", port, kref_read(>malloc_kref));
> > +   DRM_DEBUG("port %p/%px (%d)\n",
> > + port, port, kref_read(>malloc_kref));
> >  }
> >  EXPORT_SYMBOL(drm_dp_mst_get_port_malloc);
> >  
> > @@ -1396,7 +1399,8 @@ EXPORT_SYMBOL(drm_dp_mst_get_port_malloc);
> >  void
> >  drm_dp_mst_put_port_malloc(struct drm_dp_mst_port *port)
> >  {
> > -   DRM_DEBUG("port %p (%d)\n", port, kref_read(>malloc_kref) - 1);
> > +   DRM_DEBUG("port %p/%px (%d)\n",
> > + port, port, kref_read(>malloc_kref) - 1);
> > kref_put(>malloc_kref, drm_dp_free_mst_port);
> >  }
> >  EXPORT_SYMBOL(drm_dp_mst_put_port_malloc);
> > @@ -1447,8 +1451,8 @@ drm_dp_mst_topology_try_get_mstb(struct
> > drm_dp_mst_branch *mstb)
> > int ret = kref_get_unless_zero(>topology_kref);
> >  
> > if (ret)
> > -   DRM_DEBUG("mstb %p (%d)\n", mstb,
> > - kref_read(>topology_kref));
> > +   DRM_DEBUG("mstb %p/%px (%d)\n",
> > + mstb, mstb, kref_read(>topology_kref));
> >  
> > return ret;
> >  }
> > @@ -1471,7 +1475,8 @@ static void drm_dp_mst_topology_get_mstb(struct
> > drm_dp_mst_branch *mstb)
> >  {
> > WARN_ON(kref_read(>topology_kref) == 0);
> > kref_get(>topology_kref);
> > -   DRM_DEBUG("mstb %p (%d)\n", mstb, kref_read(>topology_kref));
> > +   DRM_DEBUG("mstb %p/%px (%d)\n",
> > + mstb, mstb, kref_read(>topology_kref));
> >  }
> >  
> >  /**
> > @@ -1489,8 +1494,8 @@ static void drm_dp_mst_topology_get_mstb(struct
> > drm_dp_mst_branch *mstb)
> >  static void
> >  drm_dp_mst_topology_put_mstb(struct drm_dp_mst_branch *mstb)
> >  {
> > -   DRM_DEBUG("mstb %p (%d)\n",
> > - mstb, kref_read(>topology_kref) - 1);
> > +   DRM_DEBUG("mstb %p/%px (%d)\n",
> > + mstb, mstb, kref_read(>topology_kref) - 1);
> > kref_put(>topology_kref, drm_dp_destroy_mst_branch_device);
> >  }
> >  
> > @@ -1546,8 +1551,8 @@ drm_dp_mst_topology_try_get_port(struct
> > drm_dp_mst_port *port)
> > int ret = kref_get_unless_zero(>topology_kref);
> >  
> > if (ret)
> > -   

Re: [PATCH RFC v4 14/16] drm, cgroup: Introduce lgpu as DRM cgroup resource

[Daniel Vetter]

On Wed, Oct 9, 2019 at 8:52 PM Greathouse, Joseph
 wrote:
>
> > From: Daniel Vetter  On Behalf Of Daniel Vetter
> > Sent: Wednesday, October 9, 2019 11:07 AM
> > On Wed, Oct 09, 2019 at 03:53:42PM +, Kuehling, Felix wrote:
> > > On 2019-10-09 11:34, Daniel Vetter wrote:
> > > > On Wed, Oct 09, 2019 at 03:25:22PM +, Kuehling, Felix wrote:
> > > >> On 2019-10-09 6:31, Daniel Vetter wrote:
> > > >>> On Tue, Oct 08, 2019 at 06:53:18PM +, Kuehling, Felix wrote:
> > >  The description sounds reasonable to me and maps well to the CU 
> > >  masking
> > >  feature in our GPUs.
> > > 
> > >  It would also allow us to do more coarse-grained masking for example 
> > >  to
> > >  guarantee balanced allocation of CUs across shader engines or
> > >  partitioning of memory bandwidth or CP pipes (if that is supported by
> > >  the hardware/firmware).
> > > >>> Hm, so this sounds like the definition for how this cgroup is 
> > > >>> supposed to
> > > >>> work is "amd CU masking" (whatever that exactly is). And the abstract
> > > >>> description is just prettification on top, but not actually the real
> > > >>> definition you guys want.
> > > >> I think you're reading this as the opposite of what I was trying to 
> > > >> say.
> > > >> Using CU masking is one possible implementation of LGPUs on AMD
> > > >> hardware. It's the one that Kenny implemented at the end of this patch
> > > >> series, and I pointed out some problems with that approach. Other ways
> > > >> to partition the hardware into LGPUs are conceivable. For example we're
> > > >> considering splitting it along the lines of shader engines, which is
> > > >> more coarse-grain and would also affect memory bandwidth available to
> > > >> each partition.
> > > > If this is supposed to be useful for admins then "other ways to 
> > > > partition
> > > > the hw are conceivable" is the problem. This should be unique for
> > > > admins/end-users. Reading the implementation details and realizing that
> > > > the actual meaning is "amd CU masking" isn't good enough by far, since
> > > > that's meaningless on any other hw.
> > > >
> > > > And if there's other ways to implement this cgroup for amd, it's also
> > > > meaningless (to sysadmins/users) for amd hw.
> > > >
> > > >> We could also consider partitioning pipes in our command processor,
> > > >> although that is not supported by our current CP scheduler firmware.
> > > >>
> > > >> The bottom line is, the LGPU model proposed by Kenny is quite abstract
> > > >> and allows drivers implementing it a lot of flexibility depending on 
> > > >> the
> > > >> capability of their hardware and firmware. We haven't settled on a 
> > > >> final
> > > >> implementation choice even for AMD.
> > > > That abstract model of essentially "anything goes" is the problem here
> > > > imo. E.g. for cpu cgroups this would be similar to allowing the bitmaks 
> > > > to
> > > > mean "cpu core" on one machine "physical die" on the next and maybe
> > > > "hyperthread unit" on the 3rd. Useless for admins.
> > > >
> > > > So if we have a gpu bitmaks thing that might mean a command submissio 
> > > > pipe
> > > > on one hw (maybe matching what vk exposed, maybe not), some compute unit
> > > > mask on the next and something entirely different (e.g. intel has so
> > > > called GT slices with compute cores + more stuff around) on the 3rd 
> > > > vendor
> > > > then that's not useful for admins.
> > >
> > > The goal is to partition GPU compute resources to eliminate as much
> > > resource contention as possible between different partitions. Different
> > > hardware will have different capabilities to implement this. No
> > > implementation will be perfect. For example, even with CPU cores that
> > > are supposedly well defined, you can still have different behaviours
> > > depending on CPU cache architectures, NUMA and thermal management across
> > > CPU cores. The admin will need some knowledge of their hardware
> > > architecture to understand those effects that are not described by the
> > > abstract model of cgroups.
> >
> > That's not the point I was making. For cpu cgroups there's a very well
> > defined connection between the cpu bitmasks/numbers in cgroups and the cpu
> > bitmasks you use in various system calls (they match). And that stuff
> > works across vendors.
> >
> > We need the same for gpus.
> >
> > > The LGPU model is deliberately flexible, because GPU architectures are
> > > much less standardized than CPU architectures. Expecting a common model
> > > that is both very specific and applicable to to all GPUs is unrealistic,
> > > in my opinion.
> >
> > So pure abstraction isn't useful, we need to know what these bits mean.
> > Since if they e.g. mean vk pipes, then maybe I shouldn't be using those vk
> > pipes in my application anymore. Or we need to define that the userspace
> > driver needs to filter out any pipes that arent' accessible (if that's
> > possible, no idea).
> >
> > 

Re: [PATCH v2 25/27] drm/dp_mst: Add basic topology reprobing when resuming

[Lyude Paul]

On Fri, 2019-09-27 at 09:52 -0400, Sean Paul wrote:
> On Tue, Sep 03, 2019 at 04:46:03PM -0400, Lyude Paul wrote:
> > Finally! For a very long time, our MST helpers have had one very
> > annoying issue: They don't know how to reprobe the topology state when
> > coming out of suspend. This means that if a user has a machine connected
> > to an MST topology and decides to suspend their machine, we lose all
> > topology changes that happened during that period. That can be a big
> > problem if the machine was connected to a different topology on the same
> > port before resuming, as we won't bother reprobing any of the ports and
> > likely cause the user's monitors not to come back up as expected.
> > 
> > So, we start fixing this by teaching our MST helpers how to reprobe the
> > link addresses of each connected topology when resuming. As it turns
> > out, the behavior that we want here is identical to the behavior we want
> > when initially probing a newly connected MST topology, with a couple of
> > important differences:
> > 
> > - We need to be more careful about handling the potential races between
> >   events from the MST hub that could change the topology state as we're
> >   performing the link address reprobe
> > - We need to be more careful about handling unlikely state changes on
> >   ports - such as an input port turning into an output port, something
> >   that would be far more likely to happen in situations like the MST hub
> >   we're connected to being changed while we're suspend
> > 
> > Both of which have been solved by previous commits. That leaves one
> > requirement:
> > 
> > - We need to prune any MST ports in our in-memory topology state that
> >   were present when suspending, but have not appeared in the post-resume
> >   link address response from their parent branch device
> > 
> > Which we can now handle in this commit by modifying
> > drm_dp_send_link_address(). We then introduce suspend/resume reprobing
> > by introducing drm_dp_mst_topology_mgr_invalidate_mstb(), which we call
> > in drm_dp_mst_topology_mgr_suspend() to traverse the in-memory topology
> > state to indicate that each mstb needs it's link address resent and PBN
> > resources reprobed.
> > 
> > On resume, we start back up >work and have it reprobe the topology
> > in the same way we would on a hotplug, removing any leftover ports that
> > no longer appear in the topology state.
> > 
> > Cc: Juston Li 
> > Cc: Imre Deak 
> > Cc: Ville Syrjälä 
> > Cc: Harry Wentland 
> > Cc: Daniel Vetter 
> > Signed-off-by: Lyude Paul 
> > ---
> >  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |   2 +-
> >  drivers/gpu/drm/drm_dp_mst_topology.c | 138 +-
> >  drivers/gpu/drm/i915/display/intel_dp.c   |   3 +-
> >  drivers/gpu/drm/nouveau/dispnv50/disp.c   |   6 +-
> >  include/drm/drm_dp_mst_helper.h   |   3 +-
> >  5 files changed, 112 insertions(+), 40 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 4d3c8bff77da..27ee3e045b86 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > @@ -973,7 +973,7 @@ static void s3_handle_mst(struct drm_device *dev, bool
> > suspend)
> > if (suspend) {
> > drm_dp_mst_topology_mgr_suspend(mgr);
> > } else {
> > -   ret = drm_dp_mst_topology_mgr_resume(mgr);
> > +   ret = drm_dp_mst_topology_mgr_resume(mgr, true);
> > if (ret < 0) {
> > drm_dp_mst_topology_mgr_set_mst(mgr, false);
> > need_hotplug = true;
> > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > index e407aba1fbd2..2fe24e366925 100644
> > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > @@ -2020,6 +2020,14 @@ drm_dp_mst_handle_link_address_port(struct
> > drm_dp_mst_branch *mstb,
> > goto fail_unlock;
> > }
> >  
> > +   /*
> > +* If this port wasn't just created, then we're reprobing because
> > +* we're coming out of suspend. In this case, always resend the link
> > +* address if there's an MSTB on this port
> > +*/
> > +   if (!created && port->pdt == DP_PEER_DEVICE_MST_BRANCHING)
> > +   send_link_addr = true;
> > +
> > if (send_link_addr) {
> > mutex_lock(>lock);
> > if (port->mstb) {
> > @@ -2530,7 +2538,8 @@ static void drm_dp_send_link_address(struct
> > drm_dp_mst_topology_mgr *mgr,
> >  {
> > struct drm_dp_sideband_msg_tx *txmsg;
> > struct drm_dp_link_address_ack_reply *reply;
> > -   int i, len, ret;
> > +   struct drm_dp_mst_port *port, *tmp;
> > +   int i, len, ret, port_mask = 0;
> >  
> > txmsg = kzalloc(sizeof(*txmsg), GFP_KERNEL);
> > if (!txmsg)
> > @@ -2560,9 +2569,28 

RE: [PATCH RFC v4 14/16] drm, cgroup: Introduce lgpu as DRM cgroup resource

[Greathouse, Joseph]

> From: Daniel Vetter  On Behalf Of Daniel Vetter
> Sent: Wednesday, October 9, 2019 11:07 AM
> On Wed, Oct 09, 2019 at 03:53:42PM +, Kuehling, Felix wrote:
> > On 2019-10-09 11:34, Daniel Vetter wrote:
> > > On Wed, Oct 09, 2019 at 03:25:22PM +, Kuehling, Felix wrote:
> > >> On 2019-10-09 6:31, Daniel Vetter wrote:
> > >>> On Tue, Oct 08, 2019 at 06:53:18PM +, Kuehling, Felix wrote:
> >  The description sounds reasonable to me and maps well to the CU masking
> >  feature in our GPUs.
> > 
> >  It would also allow us to do more coarse-grained masking for example to
> >  guarantee balanced allocation of CUs across shader engines or
> >  partitioning of memory bandwidth or CP pipes (if that is supported by
> >  the hardware/firmware).
> > >>> Hm, so this sounds like the definition for how this cgroup is supposed 
> > >>> to
> > >>> work is "amd CU masking" (whatever that exactly is). And the abstract
> > >>> description is just prettification on top, but not actually the real
> > >>> definition you guys want.
> > >> I think you're reading this as the opposite of what I was trying to say.
> > >> Using CU masking is one possible implementation of LGPUs on AMD
> > >> hardware. It's the one that Kenny implemented at the end of this patch
> > >> series, and I pointed out some problems with that approach. Other ways
> > >> to partition the hardware into LGPUs are conceivable. For example we're
> > >> considering splitting it along the lines of shader engines, which is
> > >> more coarse-grain and would also affect memory bandwidth available to
> > >> each partition.
> > > If this is supposed to be useful for admins then "other ways to partition
> > > the hw are conceivable" is the problem. This should be unique for
> > > admins/end-users. Reading the implementation details and realizing that
> > > the actual meaning is "amd CU masking" isn't good enough by far, since
> > > that's meaningless on any other hw.
> > >
> > > And if there's other ways to implement this cgroup for amd, it's also
> > > meaningless (to sysadmins/users) for amd hw.
> > >
> > >> We could also consider partitioning pipes in our command processor,
> > >> although that is not supported by our current CP scheduler firmware.
> > >>
> > >> The bottom line is, the LGPU model proposed by Kenny is quite abstract
> > >> and allows drivers implementing it a lot of flexibility depending on the
> > >> capability of their hardware and firmware. We haven't settled on a final
> > >> implementation choice even for AMD.
> > > That abstract model of essentially "anything goes" is the problem here
> > > imo. E.g. for cpu cgroups this would be similar to allowing the bitmaks to
> > > mean "cpu core" on one machine "physical die" on the next and maybe
> > > "hyperthread unit" on the 3rd. Useless for admins.
> > >
> > > So if we have a gpu bitmaks thing that might mean a command submissio pipe
> > > on one hw (maybe matching what vk exposed, maybe not), some compute unit
> > > mask on the next and something entirely different (e.g. intel has so
> > > called GT slices with compute cores + more stuff around) on the 3rd vendor
> > > then that's not useful for admins.
> >
> > The goal is to partition GPU compute resources to eliminate as much
> > resource contention as possible between different partitions. Different
> > hardware will have different capabilities to implement this. No
> > implementation will be perfect. For example, even with CPU cores that
> > are supposedly well defined, you can still have different behaviours
> > depending on CPU cache architectures, NUMA and thermal management across
> > CPU cores. The admin will need some knowledge of their hardware
> > architecture to understand those effects that are not described by the
> > abstract model of cgroups.
> 
> That's not the point I was making. For cpu cgroups there's a very well
> defined connection between the cpu bitmasks/numbers in cgroups and the cpu
> bitmasks you use in various system calls (they match). And that stuff
> works across vendors.
> 
> We need the same for gpus.
> 
> > The LGPU model is deliberately flexible, because GPU architectures are
> > much less standardized than CPU architectures. Expecting a common model
> > that is both very specific and applicable to to all GPUs is unrealistic,
> > in my opinion.
> 
> So pure abstraction isn't useful, we need to know what these bits mean.
> Since if they e.g. mean vk pipes, then maybe I shouldn't be using those vk
> pipes in my application anymore. Or we need to define that the userspace
> driver needs to filter out any pipes that arent' accessible (if that's
> possible, no idea).
> 
> cgroups that essentially have pure hw depedent meaning aren't useful.
> Note: this is about the fundamental meaning, not about the more unclear
> isolation guarantees (which are indeed hw specific on different cpu
> platforms). We're not talking about "different gpus might have different
> amounts of shared caches 

Re: drm/amd/display: Add HDCP module - static analysis bug report

[Daniel Vetter]

On Wed, Oct 9, 2019 at 8:23 PM Lakha, Bhawanpreet
 wrote:
>
> Hi,
>
> The reason we don't use drm_hdcp is because our policy is to do hdcp
> verification using PSP/HW (onboard secure processor).

i915 also uses hw to auth, we still use the parts from drm_hdcp ...
Did you actually look at what's in there? It's essentially just shared
defines and data structures from the standard, plus a few minimal
helpers to en/decode some bits. Just from a quick read the entire
patch very much looks like midlayer everywhere design that we
discussed back when DC landed ...
-Daniel

>
> Bhawan
>
> On 2019-10-09 12:32 p.m., Daniel Vetter wrote:
> > On Thu, Oct 03, 2019 at 11:08:03PM +0100, Colin Ian King wrote:
> >> Hi,
> >>
> >> Static analysis with Coverity has detected a potential issue with
> >> function validate_bksv in
> >> drivers/gpu/drm/amd/display/modules/hdcp/hdcp1_execution.c with recent
> >> commit:
> >>
> >> commit ed9d8e2bcb003ec94658cafe9b1bb3960e2139ec
> >> Author: Bhawanpreet Lakha 
> >> Date:   Tue Aug 6 17:52:01 2019 -0400
> >>
> >>  drm/amd/display: Add HDCP module
> > I think the real question here is ... why is this not using drm_hdcp?
> > -Daniel
> >
> >>
> >> The analysis is as follows:
> >>
> >>   28 static inline enum mod_hdcp_status validate_bksv(struct mod_hdcp 
> >> *hdcp)
> >>   29 {
> >>
> >> CID 89852 (#1 of 1): Out-of-bounds read (OVERRUN)
> >>
> >> 1. overrun-local:
> >> Overrunning array of 5 bytes at byte offset 7 by dereferencing pointer
> >> (uint64_t *)hdcp->auth.msg.hdcp1.bksv.
> >>
> >>   30uint64_t n = *(uint64_t *)hdcp->auth.msg.hdcp1.bksv;
> >>   31uint8_t count = 0;
> >>   32
> >>   33while (n) {
> >>   34count++;
> >>   35n &= (n - 1);
> >>   36}
> >>
> >> hdcp->auth.msg.hdcp1.bksv is an array of 5 uint8_t as defined in
> >> drivers/gpu/drm/amd/display/modules/hdcp/hdcp.h as follows:
> >>
> >> struct mod_hdcp_message_hdcp1 {
> >>  uint8_t an[8];
> >>  uint8_t aksv[5];
> >>  uint8_t ainfo;
> >>  uint8_t bksv[5];
> >>  uint16_tr0p;
> >>  uint8_t bcaps;
> >>  uint16_tbstatus;
> >>  uint8_t ksvlist[635];
> >>  uint16_tksvlist_size;
> >>  uint8_t vp[20];
> >>
> >>  uint16_tbinfo_dp;
> >> };
> >>
> >> variable n is going to contain the contains of r0p and bcaps. I'm not
> >> sure if that is intentional. If not, then the count is going to be
> >> incorrect if these are non-zero.
> >>
> >> Colin
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: drm/amd/display: Add HDCP module - static analysis bug report

[Lakha, Bhawanpreet]

Hi,

The reason we don't use drm_hdcp is because our policy is to do hdcp 
verification using PSP/HW (onboard secure processor).

Bhawan

On 2019-10-09 12:32 p.m., Daniel Vetter wrote:
> On Thu, Oct 03, 2019 at 11:08:03PM +0100, Colin Ian King wrote:
>> Hi,
>>
>> Static analysis with Coverity has detected a potential issue with
>> function validate_bksv in
>> drivers/gpu/drm/amd/display/modules/hdcp/hdcp1_execution.c with recent
>> commit:
>>
>> commit ed9d8e2bcb003ec94658cafe9b1bb3960e2139ec
>> Author: Bhawanpreet Lakha 
>> Date:   Tue Aug 6 17:52:01 2019 -0400
>>
>>  drm/amd/display: Add HDCP module
> I think the real question here is ... why is this not using drm_hdcp?
> -Daniel
>
>>
>> The analysis is as follows:
>>
>>   28 static inline enum mod_hdcp_status validate_bksv(struct mod_hdcp *hdcp)
>>   29 {
>>
>> CID 89852 (#1 of 1): Out-of-bounds read (OVERRUN)
>>
>> 1. overrun-local:
>> Overrunning array of 5 bytes at byte offset 7 by dereferencing pointer
>> (uint64_t *)hdcp->auth.msg.hdcp1.bksv.
>>
>>   30uint64_t n = *(uint64_t *)hdcp->auth.msg.hdcp1.bksv;
>>   31uint8_t count = 0;
>>   32
>>   33while (n) {
>>   34count++;
>>   35n &= (n - 1);
>>   36}
>>
>> hdcp->auth.msg.hdcp1.bksv is an array of 5 uint8_t as defined in
>> drivers/gpu/drm/amd/display/modules/hdcp/hdcp.h as follows:
>>
>> struct mod_hdcp_message_hdcp1 {
>>  uint8_t an[8];
>>  uint8_t aksv[5];
>>  uint8_t ainfo;
>>  uint8_t bksv[5];
>>  uint16_tr0p;
>>  uint8_t bcaps;
>>  uint16_tbstatus;
>>  uint8_t ksvlist[635];
>>  uint16_tksvlist_size;
>>  uint8_t vp[20];
>>
>>  uint16_tbinfo_dp;
>> };
>>
>> variable n is going to contain the contains of r0p and bcaps. I'm not
>> sure if that is intentional. If not, then the count is going to be
>> incorrect if these are non-zero.
>>
>> Colin
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH] Revert "drm/radeon: Fix EEH during kexec"

[Alex Deucher]

This reverts commit 6f7fe9a93e6c09bf988c5059403f5f88e17e21e6.

This breaks some boards.  Maybe just enable this on PPC for
now?

Bug: https://bugzilla.kernel.org/show_bug.cgi?id=205147
Signed-off-by: Alex Deucher 
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/radeon/radeon_drv.c | 8 
 1 file changed, 8 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
b/drivers/gpu/drm/radeon/radeon_drv.c
index 4267cb55bc33..2bc56f829bf7 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -378,19 +378,11 @@ radeon_pci_remove(struct pci_dev *pdev)
 static void
 radeon_pci_shutdown(struct pci_dev *pdev)
 {
-   struct drm_device *ddev = pci_get_drvdata(pdev);
-
/* if we are running in a VM, make sure the device
 * torn down properly on reboot/shutdown
 */
if (radeon_device_is_virtual())
radeon_pci_remove(pdev);
-
-   /* Some adapters need to be suspended before a
-   * shutdown occurs in order to prevent an error
-   * during kexec.
-   */
-   radeon_suspend_kms(ddev, true, true, false);
 }
 
 static int radeon_pmops_suspend(struct device *dev)
-- 
2.20.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 2/2] drm/amd/powerplay: re-enable FW_DSTATE feature bit

[Yuan, Xiaojie]

Hi Alex,

For now, gfxoff for navi10 is disabled by default, and I also verified on 
navi14 with both GFXOFF and FW_DSTATE feature bits toggled on.

Hi Kenneth / Jack,

Could you help to confirm the firmware version?

BR,
Xiaojie

From: Deucher, Alexander 
Sent: Wednesday, October 9, 2019 9:35 PM
To: Yuan, Xiaojie ; amd-gfx@lists.freedesktop.org 

Cc: Xiao, Jack ; Wang, Kevin(Yang) ; 
Zhang, Hawking ; Quan, Evan ; Feng, 
Kenneth 
Subject: Re: [PATCH 2/2] drm/amd/powerplay: re-enable FW_DSTATE feature bit

What version of firmware has the fix?  Was it recently fixed?  We should check 
the version if the old one may be out in the wild.

Alex

From: amd-gfx  on behalf of Yuan, 
Xiaojie 
Sent: Wednesday, October 9, 2019 7:08 AM
To: amd-gfx@lists.freedesktop.org 
Cc: Xiao, Jack ; Wang, Kevin(Yang) ; 
Zhang, Hawking ; Quan, Evan ; Feng, 
Kenneth ; Yuan, Xiaojie 
Subject: [PATCH 2/2] drm/amd/powerplay: re-enable FW_DSTATE feature bit

SMU firmware has fix the bug, so remove this workaround.

Signed-off-by: Xiaojie Yuan 
---
 drivers/gpu/drm/amd/powerplay/navi10_ppt.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/navi10_ppt.c 
b/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
index 44152c1f01c7..3628295469c4 100644
--- a/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
+++ b/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
@@ -359,11 +359,8 @@ navi10_get_allowed_feature_mask(struct smu_context *smu,
 | FEATURE_MASK(FEATURE_MEM_VDDCI_SCALING_BIT)
 | FEATURE_MASK(FEATURE_MEM_MVDD_SCALING_BIT);

-   if (adev->pm.pp_feature & PP_GFXOFF_MASK) {
+   if (adev->pm.pp_feature & PP_GFXOFF_MASK)
 *(uint64_t *)feature_mask |= FEATURE_MASK(FEATURE_GFXOFF_BIT);
-   /* TODO: remove it once fw fix the bug */
-   *(uint64_t *)feature_mask &= 
~FEATURE_MASK(FEATURE_FW_DSTATE_BIT);
-   }

 if (smu->adev->pg_flags & AMD_PG_SUPPORT_MMHUB)
 *(uint64_t *)feature_mask |= 
FEATURE_MASK(FEATURE_MMHUB_PG_BIT);
--
2.20.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amdgpu/sdma5: fix mask value of POLL_REGMEM packet for pipe sync

[Deucher, Alexander]

Reviewed-by: Alex Deucher 

From: amd-gfx  on behalf of Yuan, 
Xiaojie 
Sent: Wednesday, October 9, 2019 1:09 PM
To: amd-gfx@lists.freedesktop.org 
Cc: Xiao, Jack ; Yuan, Xiaojie ; 
Zhang, Hawking 
Subject: [PATCH] drm/amdgpu/sdma5: fix mask value of POLL_REGMEM packet for 
pipe sync

sdma will hang once sequence number to be polled reaches 0x1000_

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

diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c 
b/drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c
index ad5c3566337c..3460c00f3eaa 100644
--- a/drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c
@@ -1126,7 +1126,7 @@ static void sdma_v5_0_ring_emit_pipeline_sync(struct 
amdgpu_ring *ring)
 amdgpu_ring_write(ring, addr & 0xfffc);
 amdgpu_ring_write(ring, upper_32_bits(addr) & 0x);
 amdgpu_ring_write(ring, seq); /* reference */
-   amdgpu_ring_write(ring, 0xfff); /* mask */
+   amdgpu_ring_write(ring, 0x); /* mask */
 amdgpu_ring_write(ring, SDMA_PKT_POLL_REGMEM_DW5_RETRY_COUNT(0xfff) |
   SDMA_PKT_POLL_REGMEM_DW5_INTERVAL(4)); /* retry 
count, poll interval */
 }
--
2.20.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH] drm/amdgpu/sdma5: fix mask value of POLL_REGMEM packet for pipe sync

[Yuan, Xiaojie]

sdma will hang once sequence number to be polled reaches 0x1000_

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

diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c 
b/drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c
index ad5c3566337c..3460c00f3eaa 100644
--- a/drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c
@@ -1126,7 +1126,7 @@ static void sdma_v5_0_ring_emit_pipeline_sync(struct 
amdgpu_ring *ring)
amdgpu_ring_write(ring, addr & 0xfffc);
amdgpu_ring_write(ring, upper_32_bits(addr) & 0x);
amdgpu_ring_write(ring, seq); /* reference */
-   amdgpu_ring_write(ring, 0xfff); /* mask */
+   amdgpu_ring_write(ring, 0x); /* mask */
amdgpu_ring_write(ring, SDMA_PKT_POLL_REGMEM_DW5_RETRY_COUNT(0xfff) |
  SDMA_PKT_POLL_REGMEM_DW5_INTERVAL(4)); /* retry 
count, poll interval */
 }
-- 
2.20.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: drm/amd/display: Add HDCP module - static analysis bug report

[Daniel Vetter]

On Thu, Oct 03, 2019 at 11:08:03PM +0100, Colin Ian King wrote:
> Hi,
> 
> Static analysis with Coverity has detected a potential issue with
> function validate_bksv in
> drivers/gpu/drm/amd/display/modules/hdcp/hdcp1_execution.c with recent
> commit:
> 
> commit ed9d8e2bcb003ec94658cafe9b1bb3960e2139ec
> Author: Bhawanpreet Lakha 
> Date:   Tue Aug 6 17:52:01 2019 -0400
> 
> drm/amd/display: Add HDCP module

I think the real question here is ... why is this not using drm_hdcp?
-Daniel

> 
> 
> The analysis is as follows:
> 
>  28 static inline enum mod_hdcp_status validate_bksv(struct mod_hdcp *hdcp)
>  29 {
> 
> CID 89852 (#1 of 1): Out-of-bounds read (OVERRUN)
> 
> 1. overrun-local:
> Overrunning array of 5 bytes at byte offset 7 by dereferencing pointer
> (uint64_t *)hdcp->auth.msg.hdcp1.bksv.
> 
>  30uint64_t n = *(uint64_t *)hdcp->auth.msg.hdcp1.bksv;
>  31uint8_t count = 0;
>  32
>  33while (n) {
>  34count++;
>  35n &= (n - 1);
>  36}
> 
> hdcp->auth.msg.hdcp1.bksv is an array of 5 uint8_t as defined in
> drivers/gpu/drm/amd/display/modules/hdcp/hdcp.h as follows:
> 
> struct mod_hdcp_message_hdcp1 {
> uint8_t an[8];
> uint8_t aksv[5];
> uint8_t ainfo;
> uint8_t bksv[5];
> uint16_tr0p;
> uint8_t bcaps;
> uint16_tbstatus;
> uint8_t ksvlist[635];
> uint16_tksvlist_size;
> uint8_t vp[20];
> 
> uint16_tbinfo_dp;
> };
> 
> variable n is going to contain the contains of r0p and bcaps. I'm not
> sure if that is intentional. If not, then the count is going to be
> incorrect if these are non-zero.
> 
> Colin

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH RFC v4 14/16] drm, cgroup: Introduce lgpu as DRM cgroup resource

[Daniel Vetter]

On Wed, Oct 09, 2019 at 03:53:42PM +, Kuehling, Felix wrote:
> On 2019-10-09 11:34, Daniel Vetter wrote:
> > On Wed, Oct 09, 2019 at 03:25:22PM +, Kuehling, Felix wrote:
> >> On 2019-10-09 6:31, Daniel Vetter wrote:
> >>> On Tue, Oct 08, 2019 at 06:53:18PM +, Kuehling, Felix wrote:
>  The description sounds reasonable to me and maps well to the CU masking
>  feature in our GPUs.
> 
>  It would also allow us to do more coarse-grained masking for example to
>  guarantee balanced allocation of CUs across shader engines or
>  partitioning of memory bandwidth or CP pipes (if that is supported by
>  the hardware/firmware).
> >>> Hm, so this sounds like the definition for how this cgroup is supposed to
> >>> work is "amd CU masking" (whatever that exactly is). And the abstract
> >>> description is just prettification on top, but not actually the real
> >>> definition you guys want.
> >> I think you're reading this as the opposite of what I was trying to say.
> >> Using CU masking is one possible implementation of LGPUs on AMD
> >> hardware. It's the one that Kenny implemented at the end of this patch
> >> series, and I pointed out some problems with that approach. Other ways
> >> to partition the hardware into LGPUs are conceivable. For example we're
> >> considering splitting it along the lines of shader engines, which is
> >> more coarse-grain and would also affect memory bandwidth available to
> >> each partition.
> > If this is supposed to be useful for admins then "other ways to partition
> > the hw are conceivable" is the problem. This should be unique for
> > admins/end-users. Reading the implementation details and realizing that
> > the actual meaning is "amd CU masking" isn't good enough by far, since
> > that's meaningless on any other hw.
> >
> > And if there's other ways to implement this cgroup for amd, it's also
> > meaningless (to sysadmins/users) for amd hw.
> >
> >> We could also consider partitioning pipes in our command processor,
> >> although that is not supported by our current CP scheduler firmware.
> >>
> >> The bottom line is, the LGPU model proposed by Kenny is quite abstract
> >> and allows drivers implementing it a lot of flexibility depending on the
> >> capability of their hardware and firmware. We haven't settled on a final
> >> implementation choice even for AMD.
> > That abstract model of essentially "anything goes" is the problem here
> > imo. E.g. for cpu cgroups this would be similar to allowing the bitmaks to
> > mean "cpu core" on one machine "physical die" on the next and maybe
> > "hyperthread unit" on the 3rd. Useless for admins.
> >
> > So if we have a gpu bitmaks thing that might mean a command submissio pipe
> > on one hw (maybe matching what vk exposed, maybe not), some compute unit
> > mask on the next and something entirely different (e.g. intel has so
> > called GT slices with compute cores + more stuff around) on the 3rd vendor
> > then that's not useful for admins.
> 
> The goal is to partition GPU compute resources to eliminate as much 
> resource contention as possible between different partitions. Different 
> hardware will have different capabilities to implement this. No 
> implementation will be perfect. For example, even with CPU cores that 
> are supposedly well defined, you can still have different behaviours 
> depending on CPU cache architectures, NUMA and thermal management across 
> CPU cores. The admin will need some knowledge of their hardware 
> architecture to understand those effects that are not described by the 
> abstract model of cgroups.

That's not the point I was making. For cpu cgroups there's a very well
defined connection between the cpu bitmasks/numbers in cgroups and the cpu
bitmasks you use in various system calls (they match). And that stuff
works across vendors.

We need the same for gpus.

> The LGPU model is deliberately flexible, because GPU architectures are 
> much less standardized than CPU architectures. Expecting a common model 
> that is both very specific and applicable to to all GPUs is unrealistic, 
> in my opinion.

So pure abstraction isn't useful, we need to know what these bits mean.
Since if they e.g. mean vk pipes, then maybe I shouldn't be using those vk
pipes in my application anymore. Or we need to define that the userspace
driver needs to filter out any pipes that arent' accessible (if that's
possible, no idea).

cgroups that essentially have pure hw depedent meaning aren't useful.
Note: this is about the fundamental meaning, not about the more unclear
isolation guarantees (which are indeed hw specific on different cpu
platforms). We're not talking about "different gpus might have different
amounts of shared caches bitween different bitmasks". We're talking
"different gpus might assign completely differen meaning to these
bitmasks".
-Daniel

> 
> Regards,
>    Felix
> 
> 
> > -Daniel
> >
> >> Regards,
> >>     Felix
> >>
> >>
> >>> I think adding a cgroup which is that 

Re: [PATCH RFC v4 14/16] drm, cgroup: Introduce lgpu as DRM cgroup resource

[Kuehling, Felix]

On 2019-10-09 11:34, Daniel Vetter wrote:
> On Wed, Oct 09, 2019 at 03:25:22PM +, Kuehling, Felix wrote:
>> On 2019-10-09 6:31, Daniel Vetter wrote:
>>> On Tue, Oct 08, 2019 at 06:53:18PM +, Kuehling, Felix wrote:
 The description sounds reasonable to me and maps well to the CU masking
 feature in our GPUs.

 It would also allow us to do more coarse-grained masking for example to
 guarantee balanced allocation of CUs across shader engines or
 partitioning of memory bandwidth or CP pipes (if that is supported by
 the hardware/firmware).
>>> Hm, so this sounds like the definition for how this cgroup is supposed to
>>> work is "amd CU masking" (whatever that exactly is). And the abstract
>>> description is just prettification on top, but not actually the real
>>> definition you guys want.
>> I think you're reading this as the opposite of what I was trying to say.
>> Using CU masking is one possible implementation of LGPUs on AMD
>> hardware. It's the one that Kenny implemented at the end of this patch
>> series, and I pointed out some problems with that approach. Other ways
>> to partition the hardware into LGPUs are conceivable. For example we're
>> considering splitting it along the lines of shader engines, which is
>> more coarse-grain and would also affect memory bandwidth available to
>> each partition.
> If this is supposed to be useful for admins then "other ways to partition
> the hw are conceivable" is the problem. This should be unique for
> admins/end-users. Reading the implementation details and realizing that
> the actual meaning is "amd CU masking" isn't good enough by far, since
> that's meaningless on any other hw.
>
> And if there's other ways to implement this cgroup for amd, it's also
> meaningless (to sysadmins/users) for amd hw.
>
>> We could also consider partitioning pipes in our command processor,
>> although that is not supported by our current CP scheduler firmware.
>>
>> The bottom line is, the LGPU model proposed by Kenny is quite abstract
>> and allows drivers implementing it a lot of flexibility depending on the
>> capability of their hardware and firmware. We haven't settled on a final
>> implementation choice even for AMD.
> That abstract model of essentially "anything goes" is the problem here
> imo. E.g. for cpu cgroups this would be similar to allowing the bitmaks to
> mean "cpu core" on one machine "physical die" on the next and maybe
> "hyperthread unit" on the 3rd. Useless for admins.
>
> So if we have a gpu bitmaks thing that might mean a command submissio pipe
> on one hw (maybe matching what vk exposed, maybe not), some compute unit
> mask on the next and something entirely different (e.g. intel has so
> called GT slices with compute cores + more stuff around) on the 3rd vendor
> then that's not useful for admins.

The goal is to partition GPU compute resources to eliminate as much 
resource contention as possible between different partitions. Different 
hardware will have different capabilities to implement this. No 
implementation will be perfect. For example, even with CPU cores that 
are supposedly well defined, you can still have different behaviours 
depending on CPU cache architectures, NUMA and thermal management across 
CPU cores. The admin will need some knowledge of their hardware 
architecture to understand those effects that are not described by the 
abstract model of cgroups.

The LGPU model is deliberately flexible, because GPU architectures are 
much less standardized than CPU architectures. Expecting a common model 
that is both very specific and applicable to to all GPUs is unrealistic, 
in my opinion.

Regards,
   Felix


> -Daniel
>
>> Regards,
>>     Felix
>>
>>
>>> I think adding a cgroup which is that much depending upon the hw
>>> implementation of the first driver supporting it is not a good idea.
>>> -Daniel
>>>
 I can't comment on the code as I'm unfamiliar with the details of the
 cgroup code.

 Acked-by: Felix Kuehling 


> ---
> Documentation/admin-guide/cgroup-v2.rst |  46 
> include/drm/drm_cgroup.h|   4 +
> include/linux/cgroup_drm.h  |   6 ++
> kernel/cgroup/drm.c | 135 
> 4 files changed, 191 insertions(+)
>
> diff --git a/Documentation/admin-guide/cgroup-v2.rst 
> b/Documentation/admin-guide/cgroup-v2.rst
> index 87a195133eaa..57f18469bd76 100644
> --- a/Documentation/admin-guide/cgroup-v2.rst
> +++ b/Documentation/admin-guide/cgroup-v2.rst
> @@ -1958,6 +1958,52 @@ DRM Interface Files
>   Set largest allocation for /dev/dri/card1 to 4MB
>   echo "226:1 4m" > drm.buffer.peak.max
> 
> +  drm.lgpu
> + A read-write nested-keyed file which exists on all cgroups.
> + Each entry is keyed by the DRM device's major:minor.
> +
> + lgpu stands for logical GPU, it is an abstraction 

[PATCH 3/8] drm/amdgpu: use drm_debug_enabled() to check for debug categories

[Jani Nikula]

Allow better abstraction of the drm_debug global variable in the
future. No functional changes.

Cc: Alex Deucher 
Cc: Christian König 
Cc: David (ChunMing) Zhou 
Cc: amd-gfx@lists.freedesktop.org
Acked-by: Alex Deucher 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/amd/amdgpu/smu_v11_0_i2c.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/smu_v11_0_i2c.c 
b/drivers/gpu/drm/amd/amdgpu/smu_v11_0_i2c.c
index c44723c267c9..c902f26cf50d 100644
--- a/drivers/gpu/drm/amd/amdgpu/smu_v11_0_i2c.c
+++ b/drivers/gpu/drm/amd/amdgpu/smu_v11_0_i2c.c
@@ -234,7 +234,7 @@ static uint32_t smu_v11_0_i2c_transmit(struct i2c_adapter 
*control,
DRM_DEBUG_DRIVER("I2C_Transmit(), address = %x, bytes = %d , data: ",
 (uint16_t)address, numbytes);
 
-   if (drm_debug & DRM_UT_DRIVER) {
+   if (drm_debug_enabled(DRM_UT_DRIVER)) {
print_hex_dump(KERN_INFO, "data: ", DUMP_PREFIX_NONE,
   16, 1, data, numbytes, false);
}
@@ -388,7 +388,7 @@ static uint32_t smu_v11_0_i2c_receive(struct i2c_adapter 
*control,
DRM_DEBUG_DRIVER("I2C_Receive(), address = %x, bytes = %d, data :",
  (uint16_t)address, bytes_received);
 
-   if (drm_debug & DRM_UT_DRIVER) {
+   if (drm_debug_enabled(DRM_UT_DRIVER)) {
print_hex_dump(KERN_INFO, "data: ", DUMP_PREFIX_NONE,
   16, 1, data, bytes_received, false);
}
-- 
2.20.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH RFC v4 14/16] drm, cgroup: Introduce lgpu as DRM cgroup resource

[Daniel Vetter]

On Wed, Oct 09, 2019 at 03:25:22PM +, Kuehling, Felix wrote:
> On 2019-10-09 6:31, Daniel Vetter wrote:
> > On Tue, Oct 08, 2019 at 06:53:18PM +, Kuehling, Felix wrote:
> >>
> >> The description sounds reasonable to me and maps well to the CU masking
> >> feature in our GPUs.
> >>
> >> It would also allow us to do more coarse-grained masking for example to
> >> guarantee balanced allocation of CUs across shader engines or
> >> partitioning of memory bandwidth or CP pipes (if that is supported by
> >> the hardware/firmware).
> > Hm, so this sounds like the definition for how this cgroup is supposed to
> > work is "amd CU masking" (whatever that exactly is). And the abstract
> > description is just prettification on top, but not actually the real
> > definition you guys want.
> 
> I think you're reading this as the opposite of what I was trying to say. 
> Using CU masking is one possible implementation of LGPUs on AMD 
> hardware. It's the one that Kenny implemented at the end of this patch 
> series, and I pointed out some problems with that approach. Other ways 
> to partition the hardware into LGPUs are conceivable. For example we're 
> considering splitting it along the lines of shader engines, which is 
> more coarse-grain and would also affect memory bandwidth available to 
> each partition.

If this is supposed to be useful for admins then "other ways to partition
the hw are conceivable" is the problem. This should be unique for
admins/end-users. Reading the implementation details and realizing that
the actual meaning is "amd CU masking" isn't good enough by far, since
that's meaningless on any other hw.

And if there's other ways to implement this cgroup for amd, it's also
meaningless (to sysadmins/users) for amd hw.

> We could also consider partitioning pipes in our command processor, 
> although that is not supported by our current CP scheduler firmware.
> 
> The bottom line is, the LGPU model proposed by Kenny is quite abstract 
> and allows drivers implementing it a lot of flexibility depending on the 
> capability of their hardware and firmware. We haven't settled on a final 
> implementation choice even for AMD.

That abstract model of essentially "anything goes" is the problem here
imo. E.g. for cpu cgroups this would be similar to allowing the bitmaks to
mean "cpu core" on one machine "physical die" on the next and maybe
"hyperthread unit" on the 3rd. Useless for admins.

So if we have a gpu bitmaks thing that might mean a command submissio pipe
on one hw (maybe matching what vk exposed, maybe not), some compute unit
mask on the next and something entirely different (e.g. intel has so
called GT slices with compute cores + more stuff around) on the 3rd vendor
then that's not useful for admins.
-Daniel

> 
> Regards,
>    Felix
> 
> 
> >
> > I think adding a cgroup which is that much depending upon the hw
> > implementation of the first driver supporting it is not a good idea.
> > -Daniel
> >
> >> I can't comment on the code as I'm unfamiliar with the details of the
> >> cgroup code.
> >>
> >> Acked-by: Felix Kuehling 
> >>
> >>
> >>> ---
> >>>Documentation/admin-guide/cgroup-v2.rst |  46 
> >>>include/drm/drm_cgroup.h|   4 +
> >>>include/linux/cgroup_drm.h  |   6 ++
> >>>kernel/cgroup/drm.c | 135 
> >>>4 files changed, 191 insertions(+)
> >>>
> >>> diff --git a/Documentation/admin-guide/cgroup-v2.rst 
> >>> b/Documentation/admin-guide/cgroup-v2.rst
> >>> index 87a195133eaa..57f18469bd76 100644
> >>> --- a/Documentation/admin-guide/cgroup-v2.rst
> >>> +++ b/Documentation/admin-guide/cgroup-v2.rst
> >>> @@ -1958,6 +1958,52 @@ DRM Interface Files
> >>>   Set largest allocation for /dev/dri/card1 to 4MB
> >>>   echo "226:1 4m" > drm.buffer.peak.max
> >>>
> >>> +  drm.lgpu
> >>> + A read-write nested-keyed file which exists on all cgroups.
> >>> + Each entry is keyed by the DRM device's major:minor.
> >>> +
> >>> + lgpu stands for logical GPU, it is an abstraction used to
> >>> + subdivide a physical DRM device for the purpose of resource
> >>> + management.
> >>> +
> >>> + The lgpu is a discrete quantity that is device specific (i.e.
> >>> + some DRM devices may have 64 lgpus while others may have 100
> >>> + lgpus.)  The lgpu is a single quantity with two representations
> >>> + denoted by the following nested keys.
> >>> +
> >>> +   = 
> >>> +   count Representing lgpu as anonymous resource
> >>> +   list  Representing lgpu as named resource
> >>> +   = 
> >>> +
> >>> + For example:
> >>> + 226:0 count=256 list=0-255
> >>> + 226:1 count=4 list=0,2,4,6
> >>> + 226:2 count=32 list=32-63
> >>> +
> >>> + lgpu is represented by a bitmap and uses the bitmap_parselist
> >>> + kernel function so the list key input format is a
> >>> + comma-separated list of decimal numbers 

Re: [PATCH RFC v4 14/16] drm, cgroup: Introduce lgpu as DRM cgroup resource

[Kuehling, Felix]

On 2019-10-09 6:31, Daniel Vetter wrote:
> On Tue, Oct 08, 2019 at 06:53:18PM +, Kuehling, Felix wrote:
>>
>> The description sounds reasonable to me and maps well to the CU masking
>> feature in our GPUs.
>>
>> It would also allow us to do more coarse-grained masking for example to
>> guarantee balanced allocation of CUs across shader engines or
>> partitioning of memory bandwidth or CP pipes (if that is supported by
>> the hardware/firmware).
> Hm, so this sounds like the definition for how this cgroup is supposed to
> work is "amd CU masking" (whatever that exactly is). And the abstract
> description is just prettification on top, but not actually the real
> definition you guys want.

I think you're reading this as the opposite of what I was trying to say. 
Using CU masking is one possible implementation of LGPUs on AMD 
hardware. It's the one that Kenny implemented at the end of this patch 
series, and I pointed out some problems with that approach. Other ways 
to partition the hardware into LGPUs are conceivable. For example we're 
considering splitting it along the lines of shader engines, which is 
more coarse-grain and would also affect memory bandwidth available to 
each partition.

We could also consider partitioning pipes in our command processor, 
although that is not supported by our current CP scheduler firmware.

The bottom line is, the LGPU model proposed by Kenny is quite abstract 
and allows drivers implementing it a lot of flexibility depending on the 
capability of their hardware and firmware. We haven't settled on a final 
implementation choice even for AMD.

Regards,
   Felix


>
> I think adding a cgroup which is that much depending upon the hw
> implementation of the first driver supporting it is not a good idea.
> -Daniel
>
>> I can't comment on the code as I'm unfamiliar with the details of the
>> cgroup code.
>>
>> Acked-by: Felix Kuehling 
>>
>>
>>> ---
>>>Documentation/admin-guide/cgroup-v2.rst |  46 
>>>include/drm/drm_cgroup.h|   4 +
>>>include/linux/cgroup_drm.h  |   6 ++
>>>kernel/cgroup/drm.c | 135 
>>>4 files changed, 191 insertions(+)
>>>
>>> diff --git a/Documentation/admin-guide/cgroup-v2.rst 
>>> b/Documentation/admin-guide/cgroup-v2.rst
>>> index 87a195133eaa..57f18469bd76 100644
>>> --- a/Documentation/admin-guide/cgroup-v2.rst
>>> +++ b/Documentation/admin-guide/cgroup-v2.rst
>>> @@ -1958,6 +1958,52 @@ DRM Interface Files
>>> Set largest allocation for /dev/dri/card1 to 4MB
>>> echo "226:1 4m" > drm.buffer.peak.max
>>>
>>> +  drm.lgpu
>>> +   A read-write nested-keyed file which exists on all cgroups.
>>> +   Each entry is keyed by the DRM device's major:minor.
>>> +
>>> +   lgpu stands for logical GPU, it is an abstraction used to
>>> +   subdivide a physical DRM device for the purpose of resource
>>> +   management.
>>> +
>>> +   The lgpu is a discrete quantity that is device specific (i.e.
>>> +   some DRM devices may have 64 lgpus while others may have 100
>>> +   lgpus.)  The lgpu is a single quantity with two representations
>>> +   denoted by the following nested keys.
>>> +
>>> + = 
>>> + count Representing lgpu as anonymous resource
>>> + list  Representing lgpu as named resource
>>> + = 
>>> +
>>> +   For example:
>>> +   226:0 count=256 list=0-255
>>> +   226:1 count=4 list=0,2,4,6
>>> +   226:2 count=32 list=32-63
>>> +
>>> +   lgpu is represented by a bitmap and uses the bitmap_parselist
>>> +   kernel function so the list key input format is a
>>> +   comma-separated list of decimal numbers and ranges.
>>> +
>>> +   Consecutively set bits are shown as two hyphen-separated decimal
>>> +   numbers, the smallest and largest bit numbers set in the range.
>>> +   Optionally each range can be postfixed to denote that only parts
>>> +   of it should be set.  The range will divided to groups of
>>> +   specific size.
>>> +   Syntax: range:used_size/group_size
>>> +   Example: 0-1023:2/256 ==> 0,1,256,257,512,513,768,769
>>> +
>>> +   The count key is the hamming weight / hweight of the bitmap.
>>> +
>>> +   Both count and list accept the max and default keywords.
>>> +
>>> +   Some DRM devices may only support lgpu as anonymous resources.
>>> +   In such case, the significance of the position of the set bits
>>> +   in list will be ignored.
>>> +
>>> +   This lgpu resource supports the 'allocation' resource
>>> +   distribution model.
>>> +
>>>GEM Buffer Ownership
>>>
>>>
>>> diff --git a/include/drm/drm_cgroup.h b/include/drm/drm_cgroup.h
>>> index 6d9707e1eb72..a8d6be0b075b 100644
>>> --- a/include/drm/drm_cgroup.h
>>> +++ b/include/drm/drm_cgroup.h
>>> @@ -6,6 +6,7 @@
>>>
>>>#include 
>>>#include 
>>> +#include 
>>>#include 
>>>#include 
>>>
>>> @@ -28,6 +29,9 @@ 

Re: [PATCH RFC v4 14/16] drm, cgroup: Introduce lgpu as DRM cgroup resource

[Daniel Vetter]

On Wed, Oct 09, 2019 at 11:08:45AM -0400, Kenny Ho wrote:
> Hi Daniel,
> 
> Can you elaborate what you mean in more details?  The goal of lgpu is
> to provide the ability to subdivide a GPU device and give those slices
> to different users as needed.  I don't think there is anything
> controversial or vendor specific here as requests for this are well
> documented.  The underlying representation is just a bitmap, which is
> neither unprecedented nor vendor specific (bitmap is used in cpuset
> for instance.)
> 
> An implementation of this abstraction is not hardware specific either.
> For example, one can associate a virtual function in SRIOV as a lgpu.
> Alternatively, a device can also declare to have 100 lgpus and treat
> the lgpu quantity as a percentage representation of GPU subdivision.
> The fact that an abstraction works well with a vendor implementation
> does not make it a "prettification" of a vendor feature (by this
> logic, I hope you are not implying an abstraction is only valid if it
> does not work with amd CU masking because that seems fairly partisan.)
> 
> Did I misread your characterization of this patch?

Scenario: I'm a gpgpu customer, and I type some gpgpu program (probably in
cude, transpiled for amd using rocm).

How does the stuff I'm seeing in cuda (or vk compute, or whatever) map to
the bitmasks I can set in this cgroup controller?

That's the stuff which this spec needs to explain. Currently the answer is
"amd CU masking", and that's not going to work on e.g. nvidia hw. We need
to come up with end-user relevant resources/meanings for these bits which
works across vendors.

On cpu a "cpu core" is rather well-defined, and customers actually know
what it means on intel, amd, ibm powerpc or arm. Both on the program side
(e.g. what do I need to stuff into relevant system calls to run on a
specific "cpu core") and on the admin side.

We need to achieve the same for gpus. "it's a bitmask" is not even close
enough imo.
-Daniel

> 
> Regards,
> Kenny
> 
> 
> On Wed, Oct 9, 2019 at 6:31 AM Daniel Vetter  wrote:
> >
> > On Tue, Oct 08, 2019 at 06:53:18PM +, Kuehling, Felix wrote:
> > > On 2019-08-29 2:05 a.m., Kenny Ho wrote:
> > > > drm.lgpu
> > > >  A read-write nested-keyed file which exists on all cgroups.
> > > >  Each entry is keyed by the DRM device's major:minor.
> > > >
> > > >  lgpu stands for logical GPU, it is an abstraction used to
> > > >  subdivide a physical DRM device for the purpose of resource
> > > >  management.
> > > >
> > > >  The lgpu is a discrete quantity that is device specific (i.e.
> > > >  some DRM devices may have 64 lgpus while others may have 100
> > > >  lgpus.)  The lgpu is a single quantity with two representations
> > > >  denoted by the following nested keys.
> > > >
> > > >= 
> > > >count Representing lgpu as anonymous resource
> > > >list  Representing lgpu as named resource
> > > >= 
> > > >
> > > >  For example:
> > > >  226:0 count=256 list=0-255
> > > >  226:1 count=4 list=0,2,4,6
> > > >  226:2 count=32 list=32-63
> > > >
> > > >  lgpu is represented by a bitmap and uses the bitmap_parselist
> > > >  kernel function so the list key input format is a
> > > >  comma-separated list of decimal numbers and ranges.
> > > >
> > > >  Consecutively set bits are shown as two hyphen-separated 
> > > > decimal
> > > >  numbers, the smallest and largest bit numbers set in the range.
> > > >  Optionally each range can be postfixed to denote that only 
> > > > parts
> > > >  of it should be set.  The range will divided to groups of
> > > >  specific size.
> > > >  Syntax: range:used_size/group_size
> > > >  Example: 0-1023:2/256 ==> 0,1,256,257,512,513,768,769
> > > >
> > > >  The count key is the hamming weight / hweight of the bitmap.
> > > >
> > > >  Both count and list accept the max and default keywords.
> > > >
> > > >  Some DRM devices may only support lgpu as anonymous resources.
> > > >  In such case, the significance of the position of the set bits
> > > >  in list will be ignored.
> > > >
> > > >  This lgpu resource supports the 'allocation' resource
> > > >  distribution model.
> > > >
> > > > Change-Id: I1afcacf356770930c7f925df043e51ad06ceb98e
> > > > Signed-off-by: Kenny Ho 
> > >
> > > The description sounds reasonable to me and maps well to the CU masking
> > > feature in our GPUs.
> > >
> > > It would also allow us to do more coarse-grained masking for example to
> > > guarantee balanced allocation of CUs across shader engines or
> > > partitioning of memory bandwidth or CP pipes (if that is supported by
> > > the hardware/firmware).
> >
> > Hm, so this 

Re: [PATCH RFC v4 14/16] drm, cgroup: Introduce lgpu as DRM cgroup resource

[Kenny Ho]

Hi Daniel,

Can you elaborate what you mean in more details?  The goal of lgpu is
to provide the ability to subdivide a GPU device and give those slices
to different users as needed.  I don't think there is anything
controversial or vendor specific here as requests for this are well
documented.  The underlying representation is just a bitmap, which is
neither unprecedented nor vendor specific (bitmap is used in cpuset
for instance.)

An implementation of this abstraction is not hardware specific either.
For example, one can associate a virtual function in SRIOV as a lgpu.
Alternatively, a device can also declare to have 100 lgpus and treat
the lgpu quantity as a percentage representation of GPU subdivision.
The fact that an abstraction works well with a vendor implementation
does not make it a "prettification" of a vendor feature (by this
logic, I hope you are not implying an abstraction is only valid if it
does not work with amd CU masking because that seems fairly partisan.)

Did I misread your characterization of this patch?

Regards,
Kenny


On Wed, Oct 9, 2019 at 6:31 AM Daniel Vetter  wrote:
>
> On Tue, Oct 08, 2019 at 06:53:18PM +, Kuehling, Felix wrote:
> > On 2019-08-29 2:05 a.m., Kenny Ho wrote:
> > > drm.lgpu
> > >  A read-write nested-keyed file which exists on all cgroups.
> > >  Each entry is keyed by the DRM device's major:minor.
> > >
> > >  lgpu stands for logical GPU, it is an abstraction used to
> > >  subdivide a physical DRM device for the purpose of resource
> > >  management.
> > >
> > >  The lgpu is a discrete quantity that is device specific (i.e.
> > >  some DRM devices may have 64 lgpus while others may have 100
> > >  lgpus.)  The lgpu is a single quantity with two representations
> > >  denoted by the following nested keys.
> > >
> > >= 
> > >count Representing lgpu as anonymous resource
> > >list  Representing lgpu as named resource
> > >= 
> > >
> > >  For example:
> > >  226:0 count=256 list=0-255
> > >  226:1 count=4 list=0,2,4,6
> > >  226:2 count=32 list=32-63
> > >
> > >  lgpu is represented by a bitmap and uses the bitmap_parselist
> > >  kernel function so the list key input format is a
> > >  comma-separated list of decimal numbers and ranges.
> > >
> > >  Consecutively set bits are shown as two hyphen-separated decimal
> > >  numbers, the smallest and largest bit numbers set in the range.
> > >  Optionally each range can be postfixed to denote that only parts
> > >  of it should be set.  The range will divided to groups of
> > >  specific size.
> > >  Syntax: range:used_size/group_size
> > >  Example: 0-1023:2/256 ==> 0,1,256,257,512,513,768,769
> > >
> > >  The count key is the hamming weight / hweight of the bitmap.
> > >
> > >  Both count and list accept the max and default keywords.
> > >
> > >  Some DRM devices may only support lgpu as anonymous resources.
> > >  In such case, the significance of the position of the set bits
> > >  in list will be ignored.
> > >
> > >  This lgpu resource supports the 'allocation' resource
> > >  distribution model.
> > >
> > > Change-Id: I1afcacf356770930c7f925df043e51ad06ceb98e
> > > Signed-off-by: Kenny Ho 
> >
> > The description sounds reasonable to me and maps well to the CU masking
> > feature in our GPUs.
> >
> > It would also allow us to do more coarse-grained masking for example to
> > guarantee balanced allocation of CUs across shader engines or
> > partitioning of memory bandwidth or CP pipes (if that is supported by
> > the hardware/firmware).
>
> Hm, so this sounds like the definition for how this cgroup is supposed to
> work is "amd CU masking" (whatever that exactly is). And the abstract
> description is just prettification on top, but not actually the real
> definition you guys want.
>
> I think adding a cgroup which is that much depending upon the hw
> implementation of the first driver supporting it is not a good idea.
> -Daniel
>
> >
> > I can't comment on the code as I'm unfamiliar with the details of the
> > cgroup code.
> >
> > Acked-by: Felix Kuehling 
> >
> >
> > > ---
> > >   Documentation/admin-guide/cgroup-v2.rst |  46 
> > >   include/drm/drm_cgroup.h|   4 +
> > >   include/linux/cgroup_drm.h  |   6 ++
> > >   kernel/cgroup/drm.c | 135 
> > >   4 files changed, 191 insertions(+)
> > >
> > > diff --git a/Documentation/admin-guide/cgroup-v2.rst 
> > > b/Documentation/admin-guide/cgroup-v2.rst
> > > index 87a195133eaa..57f18469bd76 100644
> > > --- a/Documentation/admin-guide/cgroup-v2.rst
> > > +++ 

Re: [PATCH 5/6] drm/amdgpu/dm/mst: Report possible_crtcs incorrectly, for now

[Daniel Vetter]

On Fri, Sep 27, 2019 at 11:27:41AM -0400, Sean Paul wrote:
> On Thu, Sep 26, 2019 at 06:51:07PM -0400, Lyude Paul wrote:
> > This commit is seperate from the previous one to make it easier to
> > revert in the future. Basically, there's multiple userspace applications
> > that interpret possible_crtcs very wrong:
> > 
> > https://gitlab.freedesktop.org/xorg/xserver/merge_requests/277
> > https://gitlab.gnome.org/GNOME/mutter/issues/759
> > 
> > While work is ongoing to fix these issues in userspace, we need to
> > report ->possible_crtcs incorrectly for now in order to avoid
> > introducing a regression in in userspace. Once these issues get fixed,
> > this commit should be reverted.
> > 
> > Signed-off-by: Lyude Paul 
> > Cc: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 11 +++
> >  1 file changed, 11 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 b404f1ae6df7..fe8ac801d7a5 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > @@ -4807,6 +4807,17 @@ static int amdgpu_dm_crtc_init(struct 
> > amdgpu_display_manager *dm,
> > if (!acrtc->mst_encoder)
> > goto fail;
> >  
> > +   /*
> > +* FIXME: This is a hack to workaround the following issues:
> > +*
> > +* https://gitlab.gnome.org/GNOME/mutter/issues/759
> > +* https://gitlab.freedesktop.org/xorg/xserver/merge_requests/277
> > +*
> > +* One these issues are closed, this should be removed
> 
> Even when these issues are closed, we'll still be introducing a regression if 
> we
> revert this change. Time for actually_possible_crtcs? :)
> 
> You also might want to briefly explain the u/s bug in case the links go sour.
> 
> > +*/
> > +   acrtc->mst_encoder->base.possible_crtcs =
> > +   amdgpu_dm_get_encoder_crtc_mask(dm->adev);
> 
> Why don't we put this hack in amdgpu_dm_dp_create_fake_mst_encoder()?

If we don't have the same hack for i915 mst I think we shouldn't merge
this ... broken userspace is broken.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 2/2] drm/amd/powerplay: re-enable FW_DSTATE feature bit

[Deucher, Alexander]

What version of firmware has the fix?  Was it recently fixed?  We should check 
the version if the old one may be out in the wild.

Alex

From: amd-gfx  on behalf of Yuan, 
Xiaojie 
Sent: Wednesday, October 9, 2019 7:08 AM
To: amd-gfx@lists.freedesktop.org 
Cc: Xiao, Jack ; Wang, Kevin(Yang) ; 
Zhang, Hawking ; Quan, Evan ; Feng, 
Kenneth ; Yuan, Xiaojie 
Subject: [PATCH 2/2] drm/amd/powerplay: re-enable FW_DSTATE feature bit

SMU firmware has fix the bug, so remove this workaround.

Signed-off-by: Xiaojie Yuan 
---
 drivers/gpu/drm/amd/powerplay/navi10_ppt.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/navi10_ppt.c 
b/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
index 44152c1f01c7..3628295469c4 100644
--- a/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
+++ b/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
@@ -359,11 +359,8 @@ navi10_get_allowed_feature_mask(struct smu_context *smu,
 | FEATURE_MASK(FEATURE_MEM_VDDCI_SCALING_BIT)
 | FEATURE_MASK(FEATURE_MEM_MVDD_SCALING_BIT);

-   if (adev->pm.pp_feature & PP_GFXOFF_MASK) {
+   if (adev->pm.pp_feature & PP_GFXOFF_MASK)
 *(uint64_t *)feature_mask |= FEATURE_MASK(FEATURE_GFXOFF_BIT);
-   /* TODO: remove it once fw fix the bug */
-   *(uint64_t *)feature_mask &= 
~FEATURE_MASK(FEATURE_FW_DSTATE_BIT);
-   }

 if (smu->adev->pg_flags & AMD_PG_SUPPORT_MMHUB)
 *(uint64_t *)feature_mask |= 
FEATURE_MASK(FEATURE_MMHUB_PG_BIT);
--
2.20.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH] drm/amdgpu/swSMU/navi: add feature toggles for more things

[Alex Deucher]

Add toggles for more power features.  Helpful in debugging.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/powerplay/navi10_ppt.c | 24 --
 1 file changed, 18 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/navi10_ppt.c 
b/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
index a583cf87b514..8e1f3be8ba6f 100644
--- a/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
+++ b/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
@@ -328,11 +328,7 @@ navi10_get_allowed_feature_mask(struct smu_context *smu,
memset(feature_mask, 0, sizeof(uint32_t) * num);
 
*(uint64_t *)feature_mask |= FEATURE_MASK(FEATURE_DPM_PREFETCHER_BIT)
-   | FEATURE_MASK(FEATURE_DPM_GFXCLK_BIT)
-   | FEATURE_MASK(FEATURE_DPM_SOCCLK_BIT)
| FEATURE_MASK(FEATURE_DPM_MP0CLK_BIT)
-   | FEATURE_MASK(FEATURE_DPM_LINK_BIT)
-   | FEATURE_MASK(FEATURE_GFX_ULV_BIT)
| FEATURE_MASK(FEATURE_RSMU_SMN_CG_BIT)
| FEATURE_MASK(FEATURE_DS_SOCCLK_BIT)
| FEATURE_MASK(FEATURE_PPT_BIT)
@@ -342,8 +338,6 @@ navi10_get_allowed_feature_mask(struct smu_context *smu,
| FEATURE_MASK(FEATURE_FAN_CONTROL_BIT)
| FEATURE_MASK(FEATURE_THERMAL_BIT)
| FEATURE_MASK(FEATURE_LED_DISPLAY_BIT)
-   | FEATURE_MASK(FEATURE_DPM_DCEFCLK_BIT)
-   | FEATURE_MASK(FEATURE_DS_GFXCLK_BIT)
| FEATURE_MASK(FEATURE_DS_DCEFCLK_BIT)
| FEATURE_MASK(FEATURE_FW_DSTATE_BIT)
| FEATURE_MASK(FEATURE_BACO_BIT)
@@ -352,11 +346,29 @@ navi10_get_allowed_feature_mask(struct smu_context *smu,
| FEATURE_MASK(FEATURE_APCC_DFLL_BIT)
| FEATURE_MASK(FEATURE_FW_CTF_BIT);
 
+   if (adev->pm.pp_feature & PP_SOCCLK_DPM_MASK)
+   *(uint64_t *)feature_mask |= 
FEATURE_MASK(FEATURE_DPM_SOCCLK_BIT);
+
+   if (adev->pm.pp_feature & PP_SCLK_DPM_MASK)
+   *(uint64_t *)feature_mask |= 
FEATURE_MASK(FEATURE_DPM_GFXCLK_BIT);
+
+   if (adev->pm.pp_feature & PP_PCIE_DPM_MASK)
+   *(uint64_t *)feature_mask |= FEATURE_MASK(FEATURE_DPM_LINK_BIT);
+
+   if (adev->pm.pp_feature & PP_DCEFCLK_DPM_MASK)
+   *(uint64_t *)feature_mask |= 
FEATURE_MASK(FEATURE_DPM_DCEFCLK_BIT);
+
if (adev->pm.pp_feature & PP_MCLK_DPM_MASK)
*(uint64_t *)feature_mask |= FEATURE_MASK(FEATURE_DPM_UCLK_BIT)
| FEATURE_MASK(FEATURE_MEM_VDDCI_SCALING_BIT)
| FEATURE_MASK(FEATURE_MEM_MVDD_SCALING_BIT);
 
+   if (adev->pm.pp_feature & PP_ULV_MASK)
+   *(uint64_t *)feature_mask |= FEATURE_MASK(FEATURE_GFX_ULV_BIT);
+
+   if (adev->pm.pp_feature & PP_SCLK_DEEP_SLEEP_MASK)
+   *(uint64_t *)feature_mask |= 
FEATURE_MASK(FEATURE_DS_GFXCLK_BIT);
+
if (adev->pm.pp_feature & PP_GFXOFF_MASK) {
*(uint64_t *)feature_mask |= FEATURE_MASK(FEATURE_GFXOFF_BIT);
/* TODO: remove it once fw fix the bug */
-- 
2.20.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 7/8] drm/amdgpu: reserve vram for memory training

[Yin, Tianci (Rico)]

Oh, I see, I thought we should eliminate warning, but it's a wrong idea, 
actually we need it.

Thanks!

Rico

From: Christian K?nig 
Sent: Wednesday, October 9, 2019 19:40
To: Yin, Tianci (Rico) ; Tuikov, Luben 
; Alex Deucher ; 
amd-gfx@lists.freedesktop.org 
Cc: Deucher, Alexander 
Subject: Re: [PATCH 7/8] drm/amdgpu: reserve vram for memory training

Am 09.10.19 um 13:12 schrieb Yin, Tianci (Rico):
Here is where you definitively set "ret" so DO NOT preinitialize it to 0,
just to avoid "pesky compiler unininitialized variable warnings"--those
are helpful to make the code more secure: a variable should be intentionally
initialized in all paths.

Rico: Still in confusion, pre-initialization can avoid "uninitialized 
variable", why should we can't pre-initialize?

Because it avoids the uninitialized variable warning :)

See we really want the warning because it means that we have a bug in the code 
somewhere.

Regards,
Christian.


From: Tuikov, Luben 
Sent: Wednesday, October 9, 2019 11:44
To: Alex Deucher ; 
amd-gfx@lists.freedesktop.org 

Cc: Deucher, Alexander 
; Yin, Tianci 
(Rico) 
Subject: Re: [PATCH 7/8] drm/amdgpu: reserve vram for memory training

On 2019-10-08 3:29 p.m., Alex Deucher wrote:
> From: "Tianci.Yin" 
>
> memory training using specific fixed vram segment, reserve these
> segments before anyone may allocate it.
>
> Change-Id: I1436755813a565608a2857a683f535377620a637
> Reviewed-by: Alex Deucher 
> 
> Signed-off-by: Tianci.Yin 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 96 +
>  1 file changed, 96 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> index 74a9bd94f10c..0819721af16e 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> @@ -1667,6 +1667,93 @@ static int amdgpu_ttm_fw_reserve_vram_init(struct 
> amdgpu_device *adev)
>  >fw_vram_usage.va);
>  }
>
> +/*
> + * Memoy training reservation functions
> + */

Include an empty line between the two comments, just as you would
a paragraph in written text.

> +/**
> + * amdgpu_ttm_training_reserve_vram_fini - free memory training reserved vram
> + *
> + * @adev: amdgpu_device pointer
> + *
> + * free memory training reserved vram if it has been reserved.
> + */
> +static int amdgpu_ttm_training_reserve_vram_fini(struct amdgpu_device *adev)
> +{
> + int ret = 0;
> + struct psp_memory_training_context *ctx = >psp.mem_train_ctx;
> +
> + ctx->init = PSP_MEM_TRAIN_NOT_SUPPORT;
> + if(ctx->c2p_bo) {

Space after keywords, according to LKCS:
if (...)

> + amdgpu_bo_free_kernel(>c2p_bo, NULL, NULL);
> + ctx->c2p_bo = NULL;
> + }
> + if(ctx->p2c_bo) {

Space after keywords, according to LKCS:
if (...)

> + amdgpu_bo_free_kernel(>p2c_bo, NULL, NULL);
> + ctx->p2c_bo = NULL;
> + }
> +
> + return ret;
> +}

Get rid of "ret" variable altogether as it is not used in this function.

> +
> +/**
> + * amdgpu_ttm_training_reserve_vram_init - create bo vram reservation from 
> memory training
> + *
> + * @adev: amdgpu_device pointer
> + *
> + * create bo vram reservation from memory training.
> + */
> +static int amdgpu_ttm_training_reserve_vram_init(struct amdgpu_device *adev)
> +{
> + int ret = 0;

DO NOT preinitialize ret.

> + struct psp_memory_training_context *ctx = >psp.mem_train_ctx;
> +
> + memset(ctx, 0, sizeof(*ctx));
> + if(!adev->fw_vram_usage.mem_train_support) {

Space after keywords: "if (".

> + DRM_DEBUG("memory training does not support!\n");
> + return 0;
> + }
> +
> + ctx->c2p_train_data_offset = adev->fw_vram_usage.mem_train_fb_loc;
> + ctx->p2c_train_data_offset = (adev->gmc.mc_vram_size - 
> GDDR6_MEM_TRAINING_OFFSET);
> + ctx->train_data_size = GDDR6_MEM_TRAINING_DATA_SIZE_IN_BYTES;
> +
> + 
> DRM_DEBUG("train_data_size:%llx,p2c_train_data_offset:%llx,c2p_train_data_offset:%llx.\n",
> +   ctx->train_data_size,
> +   ctx->p2c_train_data_offset,
> +   ctx->c2p_train_data_offset);
> +
> + ret = amdgpu_bo_create_kernel_at(adev,

Here is where you definitively set "ret" so DO NOT preinitialize it to 0,
just to avoid "pesky compiler unininitialized variable warnings"--those
are helpful to make the code more secure: a variable should be intentionally
initialized in all paths.

> +  ctx->p2c_train_data_offset,
> +  ctx->train_data_size,
> + 

Re: [PATCH 7/8] drm/amdgpu: reserve vram for memory training

[Christian König]

Am 09.10.19 um 13:12 schrieb Yin, Tianci (Rico):

Here is where you definitively set "ret" so DO NOT preinitialize it to 0,
just to avoid "pesky compiler unininitialized variable warnings"--those
are helpful to make the code more secure: a variable should be 
intentionally

initialized in all paths.

Rico: Still in confusion, pre-initialization can avoid "uninitialized 
variable", why should we can't pre-initialize?


Because it avoids the uninitialized variable warning :)

See we really want the warning because it means that we have a bug in 
the code somewhere.


Regards,
Christian.



*From:* Tuikov, Luben 
*Sent:* Wednesday, October 9, 2019 11:44
*To:* Alex Deucher ; 
amd-gfx@lists.freedesktop.org 
*Cc:* Deucher, Alexander ; Yin, Tianci 
(Rico) 

*Subject:* Re: [PATCH 7/8] drm/amdgpu: reserve vram for memory training
On 2019-10-08 3:29 p.m., Alex Deucher wrote:
> From: "Tianci.Yin" 
>
> memory training using specific fixed vram segment, reserve these
> segments before anyone may allocate it.
>
> Change-Id: I1436755813a565608a2857a683f535377620a637
> Reviewed-by: Alex Deucher 
> Signed-off-by: Tianci.Yin 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 96 +
>  1 file changed, 96 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c

> index 74a9bd94f10c..0819721af16e 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> @@ -1667,6 +1667,93 @@ static int 
amdgpu_ttm_fw_reserve_vram_init(struct amdgpu_device *adev)

> >fw_vram_usage.va);
>  }
>
> +/*
> + * Memoy training reservation functions
> + */

Include an empty line between the two comments, just as you would
a paragraph in written text.

> +/**
> + * amdgpu_ttm_training_reserve_vram_fini - free memory training 
reserved vram

> + *
> + * @adev: amdgpu_device pointer
> + *
> + * free memory training reserved vram if it has been reserved.
> + */
> +static int amdgpu_ttm_training_reserve_vram_fini(struct 
amdgpu_device *adev)

> +{
> + int ret = 0;
> + struct psp_memory_training_context *ctx = 
>psp.mem_train_ctx;

> +
> + ctx->init = PSP_MEM_TRAIN_NOT_SUPPORT;
> + if(ctx->c2p_bo) {

Space after keywords, according to LKCS:
if (...)

> + amdgpu_bo_free_kernel(>c2p_bo, NULL, NULL);
> + ctx->c2p_bo = NULL;
> + }
> + if(ctx->p2c_bo) {

Space after keywords, according to LKCS:
if (...)

> + amdgpu_bo_free_kernel(>p2c_bo, NULL, NULL);
> + ctx->p2c_bo = NULL;
> + }
> +
> + return ret;
> +}

Get rid of "ret" variable altogether as it is not used in this function.

> +
> +/**
> + * amdgpu_ttm_training_reserve_vram_init - create bo vram 
reservation from memory training

> + *
> + * @adev: amdgpu_device pointer
> + *
> + * create bo vram reservation from memory training.
> + */
> +static int amdgpu_ttm_training_reserve_vram_init(struct 
amdgpu_device *adev)

> +{
> + int ret = 0;

DO NOT preinitialize ret.

> + struct psp_memory_training_context *ctx = 
>psp.mem_train_ctx;

> +
> + memset(ctx, 0, sizeof(*ctx));
> + if(!adev->fw_vram_usage.mem_train_support) {

Space after keywords: "if (".

> + DRM_DEBUG("memory training does not support!\n");
> + return 0;
> + }
> +
> + ctx->c2p_train_data_offset = adev->fw_vram_usage.mem_train_fb_loc;
> + ctx->p2c_train_data_offset = (adev->gmc.mc_vram_size - 
GDDR6_MEM_TRAINING_OFFSET);

> + ctx->train_data_size = GDDR6_MEM_TRAINING_DATA_SIZE_IN_BYTES;
> +
> + 
DRM_DEBUG("train_data_size:%llx,p2c_train_data_offset:%llx,c2p_train_data_offset:%llx.\n",

> +   ctx->train_data_size,
> +   ctx->p2c_train_data_offset,
> +   ctx->c2p_train_data_offset);
> +
> + ret = amdgpu_bo_create_kernel_at(adev,

Here is where you definitively set "ret" so DO NOT preinitialize it to 0,
just to avoid "pesky compiler unininitialized variable warnings"--those
are helpful to make the code more secure: a variable should be 
intentionally

initialized in all paths.

> + ctx->p2c_train_data_offset,
> + ctx->train_data_size,
> + AMDGPU_GEM_DOMAIN_VRAM,
> + >p2c_bo,
> +  NULL);
> + if(ret) {

Space after keywords "if (".

> + DRM_ERROR("alloc p2c_bo failed(%d)!\n", ret);
> + ret = -ENOMEM;
> + goto err_out;
> + }
> +
> + ret = amdgpu_bo_create_kernel_at(adev,
> + ctx->c2p_train_data_offset,
> + ctx->train_data_size,
> + AMDGPU_GEM_DOMAIN_VRAM,
> + >c2p_bo,
> +  NULL);
> + if(ret) {

Space after keywords: "if (", according to LKCS.

Regards,
Luben

> + DRM_ERROR("alloc c2p_bo failed(%d)!\n", ret);
> + ret = -ENOMEM;
> + goto err_out;
> + }
> +
> + ctx->init = PSP_MEM_TRAIN_RESERVE_SUCCESS;
> + return 0;
> +
> +err_out:
> + 

Re: [PATCH 2/8] drm/amdgpu: add a generic fb accessing helper function

[Yin, Tianci (Rico)]

Ok,

Thanks for your reviewing!

Rico

From: Christian K?nig 
Sent: Wednesday, October 9, 2019 16:25
To: Alex Deucher ; amd-gfx@lists.freedesktop.org 

Cc: Deucher, Alexander ; Yin, Tianci (Rico) 

Subject: Re: [PATCH 2/8] drm/amdgpu: add a generic fb accessing helper function

Am 08.10.19 um 21:29 schrieb Alex Deucher:
> From: "Tianci.Yin" 
>
> add a generic helper function for accessing framebuffer via MMIO
>
> Change-Id: I4baa0aa53c93a94c2eff98c6211a61f369239982
> Reviewed-by: Alex Deucher 
> Signed-off-by: Tianci.Yin 
> ---
>   drivers/gpu/drm/amd/amdgpu/amdgpu.h   |  2 +
>   drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 42 +++
>   drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 13 +-
>   3 files changed, 45 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index 17ccb9015141..0d60c2e6c592 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -985,6 +985,8 @@ int amdgpu_device_init(struct amdgpu_device *adev,
>   void amdgpu_device_fini(struct amdgpu_device *adev);
>   int amdgpu_gpu_wait_for_idle(struct amdgpu_device *adev);
>
> +int amdgpu_device_vram_access(struct amdgpu_device *adev, loff_t pos,
> +uint32_t *buf, size_t size, bool write);
>   uint32_t amdgpu_mm_rreg(struct amdgpu_device *adev, uint32_t reg,
>uint32_t acc_flags);
>   void amdgpu_mm_wreg(struct amdgpu_device *adev, uint32_t reg, uint32_t v,
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index f25275abf408..53ce227f759c 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -153,6 +153,48 @@ bool amdgpu_device_is_px(struct drm_device *dev)
>return false;
>   }
>
> +/**
> + * VRAM access helper functions.
> + *
> + * amdgpu_device_vram_access - read/write a buffer in vram
> + *
> + * @adev: amdgpu_device pointer
> + * @pos: offset of the buffer in vram
> + * @buf: virtual address of the buffer in system memory
> + * @size: read/write size, sizeof(@buf) must > @size
> + * @write: true - write to vram, otherwise - read from vram
> + *
> + * Returns 0 on success or an -error on failure.
> + */
> +int amdgpu_device_vram_access(struct amdgpu_device *adev, loff_t pos,
> +uint32_t *buf, size_t size, bool write)

Indentation seems to be incorrect here.

> +{
> + uint64_t end = pos + size;
> + unsigned long flags;
> +
> + if (IS_ERR_OR_NULL(buf) ||
> + (adev->gmc.mc_vram_size > 0 &&
> +  end > adev->gmc.mc_vram_size)) {
> + DRM_ERROR("parameter error! pos:%llx, buf:%llx, size:%zx.\n",
> +   pos, (u64)buf, size);
> + return -EINVAL;
> + }

Please drop that, this is a purely internal functions and parameter
checking like this doesn't really make sense.

Regards,
Christian.

> +
> + while (pos < end) {
> + spin_lock_irqsave(>mmio_idx_lock, flags);
> + WREG32_NO_KIQ(mmMM_INDEX, ((uint32_t)pos) | 0x8000);
> + WREG32_NO_KIQ(mmMM_INDEX_HI, pos >> 31);
> + if (write)
> + WREG32_NO_KIQ(mmMM_DATA, *buf++);
> + else
> + *buf++ = RREG32_NO_KIQ(mmMM_DATA);
> + spin_unlock_irqrestore(>mmio_idx_lock, flags);
> + pos += 4;
> + }
> +
> + return 0;
> +}
> +
>   /*
>* MMIO register access helper functions.
>*/
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
> index db2dab3a6dff..324c2d605f54 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
> @@ -134,21 +134,10 @@ static int hw_id_map[MAX_HWIP] = {
>
>   static int amdgpu_discovery_read_binary(struct amdgpu_device *adev, uint8_t 
> *binary)
>   {
> - uint32_t *p = (uint32_t *)binary;
>uint64_t vram_size = (uint64_t)RREG32(mmRCC_CONFIG_MEMSIZE) << 20;
>uint64_t pos = vram_size - BINARY_MAX_SIZE;
> - unsigned long flags;
> -
> - while (pos < vram_size) {
> - spin_lock_irqsave(>mmio_idx_lock, flags);
> - WREG32_NO_KIQ(mmMM_INDEX, ((uint32_t)pos) | 0x8000);
> - WREG32_NO_KIQ(mmMM_INDEX_HI, pos >> 31);
> - *p++ = RREG32_NO_KIQ(mmMM_DATA);
> - spin_unlock_irqrestore(>mmio_idx_lock, flags);
> - pos += 4;
> - }
>
> - return 0;
> + return amdgpu_device_vram_access(adev, pos, (uint32_t *)binary, 
> BINARY_MAX_SIZE, false);
>   }
>
>   static uint16_t amdgpu_discovery_calculate_checksum(uint8_t *data, uint32_t 
> size)

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Recall: [PATCH 7/8] drm/amdgpu: reserve vram for memory training

[Yin, Tianci (Rico)]

Yin, Tianci (Rico) would like to recall the message, "[PATCH 7/8] drm/amdgpu: 
reserve vram for memory training".
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Recall: [PATCH 7/8] drm/amdgpu: reserve vram for memory training

[Yin, Tianci (Rico)]

Yin, Tianci (Rico) would like to recall the message, "[PATCH 7/8] drm/amdgpu: 
reserve vram for memory training".
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 7/8] drm/amdgpu: reserve vram for memory training

[Yin, Tianci (Rico)]

Here is where you definitively set "ret" so DO NOT preinitialize it to 0,
just to avoid "pesky compiler unininitialized variable warnings"--those
are helpful to make the code more secure: a variable should be intentionally
initialized in all paths.

Rico: Still in confusion, pre-initialization can avoid "uninitialized 
variable", why should we can't pre-initialize?

From: Tuikov, Luben 
Sent: Wednesday, October 9, 2019 11:44
To: Alex Deucher ; amd-gfx@lists.freedesktop.org 

Cc: Deucher, Alexander ; Yin, Tianci (Rico) 

Subject: Re: [PATCH 7/8] drm/amdgpu: reserve vram for memory training

On 2019-10-08 3:29 p.m., Alex Deucher wrote:
> From: "Tianci.Yin" 
>
> memory training using specific fixed vram segment, reserve these
> segments before anyone may allocate it.
>
> Change-Id: I1436755813a565608a2857a683f535377620a637
> Reviewed-by: Alex Deucher 
> Signed-off-by: Tianci.Yin 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 96 +
>  1 file changed, 96 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> index 74a9bd94f10c..0819721af16e 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> @@ -1667,6 +1667,93 @@ static int amdgpu_ttm_fw_reserve_vram_init(struct 
> amdgpu_device *adev)
>  >fw_vram_usage.va);
>  }
>
> +/*
> + * Memoy training reservation functions
> + */

Include an empty line between the two comments, just as you would
a paragraph in written text.

> +/**
> + * amdgpu_ttm_training_reserve_vram_fini - free memory training reserved vram
> + *
> + * @adev: amdgpu_device pointer
> + *
> + * free memory training reserved vram if it has been reserved.
> + */
> +static int amdgpu_ttm_training_reserve_vram_fini(struct amdgpu_device *adev)
> +{
> + int ret = 0;
> + struct psp_memory_training_context *ctx = >psp.mem_train_ctx;
> +
> + ctx->init = PSP_MEM_TRAIN_NOT_SUPPORT;
> + if(ctx->c2p_bo) {

Space after keywords, according to LKCS:
if (...)

> + amdgpu_bo_free_kernel(>c2p_bo, NULL, NULL);
> + ctx->c2p_bo = NULL;
> + }
> + if(ctx->p2c_bo) {

Space after keywords, according to LKCS:
if (...)

> + amdgpu_bo_free_kernel(>p2c_bo, NULL, NULL);
> + ctx->p2c_bo = NULL;
> + }
> +
> + return ret;
> +}

Get rid of "ret" variable altogether as it is not used in this function.

> +
> +/**
> + * amdgpu_ttm_training_reserve_vram_init - create bo vram reservation from 
> memory training
> + *
> + * @adev: amdgpu_device pointer
> + *
> + * create bo vram reservation from memory training.
> + */
> +static int amdgpu_ttm_training_reserve_vram_init(struct amdgpu_device *adev)
> +{
> + int ret = 0;

DO NOT preinitialize ret.

> + struct psp_memory_training_context *ctx = >psp.mem_train_ctx;
> +
> + memset(ctx, 0, sizeof(*ctx));
> + if(!adev->fw_vram_usage.mem_train_support) {

Space after keywords: "if (".

> + DRM_DEBUG("memory training does not support!\n");
> + return 0;
> + }
> +
> + ctx->c2p_train_data_offset = adev->fw_vram_usage.mem_train_fb_loc;
> + ctx->p2c_train_data_offset = (adev->gmc.mc_vram_size - 
> GDDR6_MEM_TRAINING_OFFSET);
> + ctx->train_data_size = GDDR6_MEM_TRAINING_DATA_SIZE_IN_BYTES;
> +
> + 
> DRM_DEBUG("train_data_size:%llx,p2c_train_data_offset:%llx,c2p_train_data_offset:%llx.\n",
> +   ctx->train_data_size,
> +   ctx->p2c_train_data_offset,
> +   ctx->c2p_train_data_offset);
> +
> + ret = amdgpu_bo_create_kernel_at(adev,

Here is where you definitively set "ret" so DO NOT preinitialize it to 0,
just to avoid "pesky compiler unininitialized variable warnings"--those
are helpful to make the code more secure: a variable should be intentionally
initialized in all paths.

> +  ctx->p2c_train_data_offset,
> +  ctx->train_data_size,
> +  AMDGPU_GEM_DOMAIN_VRAM,
> +  >p2c_bo,
> +  NULL);
> + if(ret) {

Space after keywords "if (".

> + DRM_ERROR("alloc p2c_bo failed(%d)!\n", ret);
> + ret = -ENOMEM;
> + goto err_out;
> + }
> +
> + ret = amdgpu_bo_create_kernel_at(adev,
> +  ctx->c2p_train_data_offset,
> +  ctx->train_data_size,
> +  AMDGPU_GEM_DOMAIN_VRAM,
> +  >c2p_bo,
> +  NULL);
> + if(ret) {

Space after keywords: "if (", according to LKCS.

Regards,
Luben

> + DRM_ERROR("alloc c2p_bo failed(%d)!\n", ret);
> + ret = -ENOMEM;
> + goto err_out;
> + }
> +
> + 

[PATCH 2/2] drm/amd/powerplay: re-enable FW_DSTATE feature bit

[Yuan, Xiaojie]

SMU firmware has fix the bug, so remove this workaround.

Signed-off-by: Xiaojie Yuan 
---
 drivers/gpu/drm/amd/powerplay/navi10_ppt.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/navi10_ppt.c 
b/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
index 44152c1f01c7..3628295469c4 100644
--- a/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
+++ b/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
@@ -359,11 +359,8 @@ navi10_get_allowed_feature_mask(struct smu_context *smu,
| FEATURE_MASK(FEATURE_MEM_VDDCI_SCALING_BIT)
| FEATURE_MASK(FEATURE_MEM_MVDD_SCALING_BIT);
 
-   if (adev->pm.pp_feature & PP_GFXOFF_MASK) {
+   if (adev->pm.pp_feature & PP_GFXOFF_MASK)
*(uint64_t *)feature_mask |= FEATURE_MASK(FEATURE_GFXOFF_BIT);
-   /* TODO: remove it once fw fix the bug */
-   *(uint64_t *)feature_mask &= 
~FEATURE_MASK(FEATURE_FW_DSTATE_BIT);
-   }
 
if (smu->adev->pg_flags & AMD_PG_SUPPORT_MMHUB)
*(uint64_t *)feature_mask |= FEATURE_MASK(FEATURE_MMHUB_PG_BIT);
-- 
2.20.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 1/2] drm/amd/powerplay: add more feature bits

[Yuan, Xiaojie]

Signed-off-by: Xiaojie Yuan 
---
 drivers/gpu/drm/amd/powerplay/navi10_ppt.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/powerplay/navi10_ppt.c 
b/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
index 5a34d01f7f7c..44152c1f01c7 100644
--- a/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
+++ b/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
@@ -337,19 +337,22 @@ navi10_get_allowed_feature_mask(struct smu_context *smu,
| FEATURE_MASK(FEATURE_PPT_BIT)
| FEATURE_MASK(FEATURE_TDC_BIT)
| FEATURE_MASK(FEATURE_GFX_EDC_BIT)
+   | FEATURE_MASK(FEATURE_APCC_PLUS_BIT)
| FEATURE_MASK(FEATURE_VR0HOT_BIT)
| FEATURE_MASK(FEATURE_FAN_CONTROL_BIT)
| FEATURE_MASK(FEATURE_THERMAL_BIT)
| FEATURE_MASK(FEATURE_LED_DISPLAY_BIT)
| FEATURE_MASK(FEATURE_DPM_DCEFCLK_BIT)
| FEATURE_MASK(FEATURE_DS_GFXCLK_BIT)
+   | FEATURE_MASK(FEATURE_DS_LCLK_BIT)
| FEATURE_MASK(FEATURE_DS_DCEFCLK_BIT)
| FEATURE_MASK(FEATURE_FW_DSTATE_BIT)
| FEATURE_MASK(FEATURE_BACO_BIT)
| FEATURE_MASK(FEATURE_ACDC_BIT)
| FEATURE_MASK(FEATURE_GFX_SS_BIT)
| FEATURE_MASK(FEATURE_APCC_DFLL_BIT)
-   | FEATURE_MASK(FEATURE_FW_CTF_BIT);
+   | FEATURE_MASK(FEATURE_FW_CTF_BIT)
+   | FEATURE_MASK(FEATURE_OUT_OF_BAND_MONITOR_BIT);
 
if (adev->pm.pp_feature & PP_MCLK_DPM_MASK)
*(uint64_t *)feature_mask |= FEATURE_MASK(FEATURE_DPM_UCLK_BIT)
-- 
2.20.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH] SWDEV-206718 drm/amdgpu: Fix tdr3 could hang with slow compute issue

[Emily Deng]

When index is 1, need to set compute ring timeout for sriov and passthrough.

Signed-off-by: Emily Deng 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 5 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 6 --
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 53ce227..2f5a015 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -2664,8 +2664,11 @@ static int amdgpu_device_get_job_timeout_settings(struct 
amdgpu_device *adev)
 * There is only one value specified and
 * it should apply to all non-compute jobs.
 */
-   if (index == 1)
+   if (index == 1) {
adev->sdma_timeout = adev->video_timeout = 
adev->gfx_timeout;
+   if (amdgpu_sriov_vf(adev) || amdgpu_passthrough(adev))
+   adev->compute_timeout = adev->gfx_timeout;
+   }
}
 
return ret;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index a88ea74..311abc8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -250,9 +250,11 @@ module_param_named(msi, amdgpu_msi, int, 0444);
  * By default(with no lockup_timeout settings), the timeout for all 
non-compute(GFX, SDMA and Video)
  * jobs is 1. And there is no timeout enforced on compute jobs.
  */
-MODULE_PARM_DESC(lockup_timeout, "GPU lockup timeout in ms (default: 1 for 
non-compute jobs and infinity timeout for compute jobs."
+MODULE_PARM_DESC(lockup_timeout, "GPU lockup timeout in ms (default: for bare 
metal 1 for non-compute jobs and infinity timeout for compute jobs; "
+   "for passthrough or sriov, 1 for all jobs."
" 0: keep default value. negative: infinity timeout), "
-   "format is [Non-Compute] or [GFX,Compute,SDMA,Video]");
+   "format: for bare metal [Non-Compute] or 
[GFX,Compute,SDMA,Video]; "
+   "for passthrough or sriov [all jobs] or 
[GFX,Compute,SDMA,Video].");
 module_param_string(lockup_timeout, amdgpu_lockup_timeout, 
sizeof(amdgpu_lockup_timeout), 0444);
 
 /**
-- 
2.7.4

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH RFC v4 14/16] drm, cgroup: Introduce lgpu as DRM cgroup resource

[Daniel Vetter]

On Tue, Oct 08, 2019 at 06:53:18PM +, Kuehling, Felix wrote:
> On 2019-08-29 2:05 a.m., Kenny Ho wrote:
> > drm.lgpu
> >  A read-write nested-keyed file which exists on all cgroups.
> >  Each entry is keyed by the DRM device's major:minor.
> >
> >  lgpu stands for logical GPU, it is an abstraction used to
> >  subdivide a physical DRM device for the purpose of resource
> >  management.
> >
> >  The lgpu is a discrete quantity that is device specific (i.e.
> >  some DRM devices may have 64 lgpus while others may have 100
> >  lgpus.)  The lgpu is a single quantity with two representations
> >  denoted by the following nested keys.
> >
> >= 
> >count Representing lgpu as anonymous resource
> >list  Representing lgpu as named resource
> >= 
> >
> >  For example:
> >  226:0 count=256 list=0-255
> >  226:1 count=4 list=0,2,4,6
> >  226:2 count=32 list=32-63
> >
> >  lgpu is represented by a bitmap and uses the bitmap_parselist
> >  kernel function so the list key input format is a
> >  comma-separated list of decimal numbers and ranges.
> >
> >  Consecutively set bits are shown as two hyphen-separated decimal
> >  numbers, the smallest and largest bit numbers set in the range.
> >  Optionally each range can be postfixed to denote that only parts
> >  of it should be set.  The range will divided to groups of
> >  specific size.
> >  Syntax: range:used_size/group_size
> >  Example: 0-1023:2/256 ==> 0,1,256,257,512,513,768,769
> >
> >  The count key is the hamming weight / hweight of the bitmap.
> >
> >  Both count and list accept the max and default keywords.
> >
> >  Some DRM devices may only support lgpu as anonymous resources.
> >  In such case, the significance of the position of the set bits
> >  in list will be ignored.
> >
> >  This lgpu resource supports the 'allocation' resource
> >  distribution model.
> >
> > Change-Id: I1afcacf356770930c7f925df043e51ad06ceb98e
> > Signed-off-by: Kenny Ho 
> 
> The description sounds reasonable to me and maps well to the CU masking 
> feature in our GPUs.
> 
> It would also allow us to do more coarse-grained masking for example to 
> guarantee balanced allocation of CUs across shader engines or 
> partitioning of memory bandwidth or CP pipes (if that is supported by 
> the hardware/firmware).

Hm, so this sounds like the definition for how this cgroup is supposed to
work is "amd CU masking" (whatever that exactly is). And the abstract
description is just prettification on top, but not actually the real
definition you guys want.

I think adding a cgroup which is that much depending upon the hw
implementation of the first driver supporting it is not a good idea.
-Daniel

> 
> I can't comment on the code as I'm unfamiliar with the details of the 
> cgroup code.
> 
> Acked-by: Felix Kuehling 
> 
> 
> > ---
> >   Documentation/admin-guide/cgroup-v2.rst |  46 
> >   include/drm/drm_cgroup.h|   4 +
> >   include/linux/cgroup_drm.h  |   6 ++
> >   kernel/cgroup/drm.c | 135 
> >   4 files changed, 191 insertions(+)
> >
> > diff --git a/Documentation/admin-guide/cgroup-v2.rst 
> > b/Documentation/admin-guide/cgroup-v2.rst
> > index 87a195133eaa..57f18469bd76 100644
> > --- a/Documentation/admin-guide/cgroup-v2.rst
> > +++ b/Documentation/admin-guide/cgroup-v2.rst
> > @@ -1958,6 +1958,52 @@ DRM Interface Files
> > Set largest allocation for /dev/dri/card1 to 4MB
> > echo "226:1 4m" > drm.buffer.peak.max
> >   
> > +  drm.lgpu
> > +   A read-write nested-keyed file which exists on all cgroups.
> > +   Each entry is keyed by the DRM device's major:minor.
> > +
> > +   lgpu stands for logical GPU, it is an abstraction used to
> > +   subdivide a physical DRM device for the purpose of resource
> > +   management.
> > +
> > +   The lgpu is a discrete quantity that is device specific (i.e.
> > +   some DRM devices may have 64 lgpus while others may have 100
> > +   lgpus.)  The lgpu is a single quantity with two representations
> > +   denoted by the following nested keys.
> > +
> > + = 
> > + count Representing lgpu as anonymous resource
> > + list  Representing lgpu as named resource
> > + = 
> > +
> > +   For example:
> > +   226:0 count=256 list=0-255
> > +   226:1 count=4 list=0,2,4,6
> > +   226:2 count=32 list=32-63
> > +
> > +   lgpu is represented by a bitmap and uses the bitmap_parselist
> > +   kernel function so the list key input format is a
> > +   comma-separated list of 

Re: [PATCH 2/8] drm/amdgpu: add a generic fb accessing helper function

[Christian König]

Am 08.10.19 um 21:29 schrieb Alex Deucher:

From: "Tianci.Yin" 

add a generic helper function for accessing framebuffer via MMIO

Change-Id: I4baa0aa53c93a94c2eff98c6211a61f369239982
Reviewed-by: Alex Deucher 
Signed-off-by: Tianci.Yin 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu.h   |  2 +
  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 42 +++
  drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 13 +-
  3 files changed, 45 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 17ccb9015141..0d60c2e6c592 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -985,6 +985,8 @@ int amdgpu_device_init(struct amdgpu_device *adev,
  void amdgpu_device_fini(struct amdgpu_device *adev);
  int amdgpu_gpu_wait_for_idle(struct amdgpu_device *adev);
  
+int amdgpu_device_vram_access(struct amdgpu_device *adev, loff_t pos,

+  uint32_t *buf, size_t size, bool write);
  uint32_t amdgpu_mm_rreg(struct amdgpu_device *adev, uint32_t reg,
uint32_t acc_flags);
  void amdgpu_mm_wreg(struct amdgpu_device *adev, uint32_t reg, uint32_t v,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index f25275abf408..53ce227f759c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -153,6 +153,48 @@ bool amdgpu_device_is_px(struct drm_device *dev)
return false;
  }
  
+/**

+ * VRAM access helper functions.
+ *
+ * amdgpu_device_vram_access - read/write a buffer in vram
+ *
+ * @adev: amdgpu_device pointer
+ * @pos: offset of the buffer in vram
+ * @buf: virtual address of the buffer in system memory
+ * @size: read/write size, sizeof(@buf) must > @size
+ * @write: true - write to vram, otherwise - read from vram
+ *
+ * Returns 0 on success or an -error on failure.
+ */
+int amdgpu_device_vram_access(struct amdgpu_device *adev, loff_t pos,
+  uint32_t *buf, size_t size, bool write)


Indentation seems to be incorrect here.


+{
+   uint64_t end = pos + size;
+   unsigned long flags;
+
+   if (IS_ERR_OR_NULL(buf) ||
+   (adev->gmc.mc_vram_size > 0 &&
+end > adev->gmc.mc_vram_size)) {
+   DRM_ERROR("parameter error! pos:%llx, buf:%llx, size:%zx.\n",
+ pos, (u64)buf, size);
+   return -EINVAL;
+   }


Please drop that, this is a purely internal functions and parameter 
checking like this doesn't really make sense.


Regards,
Christian.


+
+   while (pos < end) {
+   spin_lock_irqsave(>mmio_idx_lock, flags);
+   WREG32_NO_KIQ(mmMM_INDEX, ((uint32_t)pos) | 0x8000);
+   WREG32_NO_KIQ(mmMM_INDEX_HI, pos >> 31);
+   if (write)
+   WREG32_NO_KIQ(mmMM_DATA, *buf++);
+   else
+   *buf++ = RREG32_NO_KIQ(mmMM_DATA);
+   spin_unlock_irqrestore(>mmio_idx_lock, flags);
+   pos += 4;
+   }
+
+   return 0;
+}
+
  /*
   * MMIO register access helper functions.
   */
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
index db2dab3a6dff..324c2d605f54 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
@@ -134,21 +134,10 @@ static int hw_id_map[MAX_HWIP] = {
  
  static int amdgpu_discovery_read_binary(struct amdgpu_device *adev, uint8_t *binary)

  {
-   uint32_t *p = (uint32_t *)binary;
uint64_t vram_size = (uint64_t)RREG32(mmRCC_CONFIG_MEMSIZE) << 20;
uint64_t pos = vram_size - BINARY_MAX_SIZE;
-   unsigned long flags;
-
-   while (pos < vram_size) {
-   spin_lock_irqsave(>mmio_idx_lock, flags);
-   WREG32_NO_KIQ(mmMM_INDEX, ((uint32_t)pos) | 0x8000);
-   WREG32_NO_KIQ(mmMM_INDEX_HI, pos >> 31);
-   *p++ = RREG32_NO_KIQ(mmMM_DATA);
-   spin_unlock_irqrestore(>mmio_idx_lock, flags);
-   pos += 4;
-   }
  
-	return 0;

+   return amdgpu_device_vram_access(adev, pos, (uint32_t *)binary, 
BINARY_MAX_SIZE, false);
  }
  
  static uint16_t amdgpu_discovery_calculate_checksum(uint8_t *data, uint32_t size)


___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 0/3] drm/amd/display/dc/dce: remove some not used variables

[zhengbin]

zhengbin (3):
  drm/amd/display: Remove set but not used variables
'bl_pwm_cntl','pwm_period_cntl'
  drm/amd/display: Remove set but not used variable 'value0'
  drm/amd/display: Remove set but not used variables 'regval','speakers'

 drivers/gpu/drm/amd/display/dc/dce/dce_abm.c| 8 
 drivers/gpu/drm/amd/display/dc/dce/dce_link_encoder.c   | 3 +--
 drivers/gpu/drm/amd/display/dc/dce/dce_stream_encoder.c | 5 +
 3 files changed, 6 insertions(+), 10 deletions(-)

--
2.7.4

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 3/3] drm/amd/display: Remove set but not used variables 'regval', 'speakers'

[zhengbin]

Fixes gcc '-Wunused-but-set-variable' warning:

drivers/gpu/drm/amd/display/dc/dce/dce_stream_encoder.c: In function 
dce110_update_generic_info_packet:
drivers/gpu/drm/amd/display/dc/dce/dce_stream_encoder.c:68:11: warning: 
variable regval set but not used [-Wunused-but-set-variable]
drivers/gpu/drm/amd/display/dc/dce/dce_stream_encoder.c: In function 
dce110_se_audio_setup:
drivers/gpu/drm/amd/display/dc/dce/dce_stream_encoder.c:1331:11: warning: 
variable speakers set but not used [-Wunused-but-set-variable]

They are not used since commit 4562236b3bc0 ("drm/amd/dc:
Add dc display driver (v2)")

Reported-by: Hulk Robot 
Signed-off-by: zhengbin 
---
 drivers/gpu/drm/amd/display/dc/dce/dce_stream_encoder.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_stream_encoder.c 
b/drivers/gpu/drm/amd/display/dc/dce/dce_stream_encoder.c
index 6ed922a..1a5b673 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dce_stream_encoder.c
+++ b/drivers/gpu/drm/amd/display/dc/dce/dce_stream_encoder.c
@@ -67,7 +67,6 @@ static void dce110_update_generic_info_packet(
uint32_t packet_index,
const struct dc_info_packet *info_packet)
 {
-   uint32_t regval;
/* TODOFPGA Figure out a proper number for max_retries polling for lock
 * use 50 for now.
 */
@@ -99,7 +98,7 @@ static void dce110_update_generic_info_packet(
}
/* choose which generic packet to use */
{
-   regval = REG_READ(AFMT_VBI_PACKET_CONTROL);
+   REG_READ(AFMT_VBI_PACKET_CONTROL);
REG_UPDATE(AFMT_VBI_PACKET_CONTROL,
AFMT_GENERIC_INDEX, packet_index);
}
@@ -1335,7 +1334,6 @@ static void dce110_se_audio_setup(
 {
struct dce110_stream_encoder *enc110 = DCE110STRENC_FROM_STRENC(enc);

-   uint32_t speakers = 0;
uint32_t channels = 0;

ASSERT(audio_info);
@@ -1343,7 +1341,6 @@ static void dce110_se_audio_setup(
/* This should not happen.it does so we don't get BSOD*/
return;

-   speakers = audio_info->flags.info.ALLSPEAKERS;
channels = speakers_to_channels(audio_info->flags.speaker_flags).all;

/* setup the audio stream source select (audio -> dig mapping) */
--
2.7.4

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 2/3] drm/amd/display: Remove set but not used variable 'value0'

[zhengbin]

Fixes gcc '-Wunused-but-set-variable' warning:

drivers/gpu/drm/amd/display/dc/dce/dce_link_encoder.c: In function 
dce110_link_encoder_update_mst_stream_allocation_table:
drivers/gpu/drm/amd/display/dc/dce/dce_link_encoder.c:1229:11: warning: 
variable value0 set but not used [-Wunused-but-set-variable]

It is not used since commit 4562236b3bc0 ("drm/amd/dc:
Add dc display driver (v2)")

Reported-by: Hulk Robot 
Signed-off-by: zhengbin 
---
 drivers/gpu/drm/amd/display/dc/dce/dce_link_encoder.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_link_encoder.c 
b/drivers/gpu/drm/amd/display/dc/dce/dce_link_encoder.c
index 8527cce..e18fe69 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dce_link_encoder.c
+++ b/drivers/gpu/drm/amd/display/dc/dce/dce_link_encoder.c
@@ -1229,7 +1229,6 @@ void 
dce110_link_encoder_update_mst_stream_allocation_table(
const struct link_mst_stream_allocation_table *table)
 {
struct dce110_link_encoder *enc110 = TO_DCE110_LINK_ENC(enc);
-   uint32_t value0 = 0;
uint32_t value1 = 0;
uint32_t value2 = 0;
uint32_t slots = 0;
@@ -1330,7 +1329,7 @@ void 
dce110_link_encoder_update_mst_stream_allocation_table(
do {
udelay(10);

-   value0 = REG_READ(DP_MSE_SAT_UPDATE);
+   REG_READ(DP_MSE_SAT_UPDATE);

REG_GET(DP_MSE_SAT_UPDATE,
DP_MSE_SAT_UPDATE, );
--
2.7.4

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 1/3] drm/amd/display: Remove set but not used variables 'bl_pwm_cntl', 'pwm_period_cntl'

[zhengbin]

Fixes gcc '-Wunused-but-set-variable' warning:

drivers/gpu/drm/amd/display/dc/dce/dce_abm.c: In function 
calculate_16_bit_backlight_from_pwm:
drivers/gpu/drm/amd/display/dc/dce/dce_abm.c:83:11: warning: variable 
bl_pwm_cntl set but not used [-Wunused-but-set-variable]
drivers/gpu/drm/amd/display/dc/dce/dce_abm.c: In function 
calculate_16_bit_backlight_from_pwm:
drivers/gpu/drm/amd/display/dc/dce/dce_abm.c:82:11: warning: variable 
pwm_period_cntl set but not used [-Wunused-but-set-variable]

They are not used since commit 5e7773a219f7 ("drm/amd/display:
DMCU Compile and Load")

Reported-by: Hulk Robot 
Signed-off-by: zhengbin 
---
 drivers/gpu/drm/amd/display/dc/dce/dce_abm.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_abm.c 
b/drivers/gpu/drm/amd/display/dc/dce/dce_abm.c
index 9edd369..b306fb1 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dce_abm.c
+++ b/drivers/gpu/drm/amd/display/dc/dce/dce_abm.c
@@ -84,15 +84,15 @@ static unsigned int 
calculate_16_bit_backlight_from_pwm(struct dce_abm *abm_dce)
 {
uint64_t current_backlight;
uint32_t round_result;
-   uint32_t pwm_period_cntl, bl_period, bl_int_count;
-   uint32_t bl_pwm_cntl, bl_pwm, fractional_duty_cycle_en;
+   uint32_t bl_period, bl_int_count;
+   uint32_t bl_pwm, fractional_duty_cycle_en;
uint32_t bl_period_mask, bl_pwm_mask;

-   pwm_period_cntl = REG_READ(BL_PWM_PERIOD_CNTL);
+   REG_READ(BL_PWM_PERIOD_CNTL);
REG_GET(BL_PWM_PERIOD_CNTL, BL_PWM_PERIOD, _period);
REG_GET(BL_PWM_PERIOD_CNTL, BL_PWM_PERIOD_BITCNT, _int_count);

-   bl_pwm_cntl = REG_READ(BL_PWM_CNTL);
+   REG_READ(BL_PWM_CNTL);
REG_GET(BL_PWM_CNTL, BL_ACTIVE_INT_FRAC_CNT, (uint32_t *)(_pwm));
REG_GET(BL_PWM_CNTL, BL_PWM_FRACTIONAL_EN, _duty_cycle_en);

--
2.7.4

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx