Re: [PATCH] drm/amd/pm: fulfill the sienna cichlid UMD PSTATE profiling clocks
[AMD Official Use Only - Internal Distribution Only]
Acked-by: Alex Deucher
From: Quan, Evan
Sent: Wednesday, December 9, 2020 1:35 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Quan, Evan
Subject: [PATCH] drm/amd/pm: fulfill the sienna cichlid UMD PSTATE profiling
clocks
Fulfill the UMD PSTATE profiling clocks of sienna cichlid.
Change-Id: Ib9078c73d3fbd786080449255645ae8b9f879092
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c | 6 ++
drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.h | 4
2 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
index 74cf027e4a41..3fb70cac72ea 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
@@ -1341,12 +1341,18 @@ static int sienna_cichlid_populate_umd_state_clk(struct
smu_context *smu)
pstate_table->gfxclk_pstate.min = gfx_table->min;
pstate_table->gfxclk_pstate.peak = gfx_table->max;
+ if (gfx_table->max >= SIENNA_CICHLID_UMD_PSTATE_PROFILING_GFXCLK)
+ pstate_table->gfxclk_pstate.standard =
SIENNA_CICHLID_UMD_PSTATE_PROFILING_GFXCLK;
pstate_table->uclk_pstate.min = mem_table->min;
pstate_table->uclk_pstate.peak = mem_table->max;
+ if (mem_table->max >= SIENNA_CICHLID_UMD_PSTATE_PROFILING_MEMCLK)
+ pstate_table->uclk_pstate.standard =
SIENNA_CICHLID_UMD_PSTATE_PROFILING_MEMCLK;
pstate_table->socclk_pstate.min = soc_table->min;
pstate_table->socclk_pstate.peak = soc_table->max;
+ if (soc_table->max >= SIENNA_CICHLID_UMD_PSTATE_PROFILING_SOCCLK)
+ pstate_table->socclk_pstate.standard =
SIENNA_CICHLID_UMD_PSTATE_PROFILING_SOCCLK;
return 0;
}
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.h
b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.h
index 57e120c440ea..38cd0ece24f6 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.h
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.h
@@ -29,6 +29,10 @@ typedef enum {
POWER_SOURCE_COUNT,
} POWER_SOURCE_e;
+#define SIENNA_CICHLID_UMD_PSTATE_PROFILING_GFXCLK1825
+#define SIENNA_CICHLID_UMD_PSTATE_PROFILING_SOCCLK960
+#define SIENNA_CICHLID_UMD_PSTATE_PROFILING_MEMCLK1000
+
extern void sienna_cichlid_set_ppt_funcs(struct smu_context *smu);
#endif
--
2.29.0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amd/pm: update smu10.h WORKLOAD_PPLIB setting for raven
[AMD Official Use Only - Internal Distribution Only]
Acked-by: Alex Deucher
From: amd-gfx on behalf of
Changfeng.Zhu
Sent: Tuesday, December 8, 2020 9:06 PM
To: amd-gfx@lists.freedesktop.org ; Huang, Ray
Cc: Zhu, Changfeng
Subject: [PATCH] drm/amd/pm: update smu10.h WORKLOAD_PPLIB setting for raven
From: changzhu
From: Changfeng
When using old WORKLOAD_PPLIB setting in smu10.h, there is problem that
it can't be able to switch to mak gpu clk during compute workload.
It needs to update WORKLOAD_PPLIB setting to fix this issue.
Change-Id: Id2160a7b4a6cb8808d100de25e999714a7ccaebd
Signed-off-by: Changfeng
---
drivers/gpu/drm/amd/pm/inc/smu10.h | 14 ++
.../gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.c | 9 +++--
2 files changed, 9 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/inc/smu10.h
b/drivers/gpu/drm/amd/pm/inc/smu10.h
index b96520528240..9e837a5014c5 100644
--- a/drivers/gpu/drm/amd/pm/inc/smu10.h
+++ b/drivers/gpu/drm/amd/pm/inc/smu10.h
@@ -136,14 +136,12 @@
#define FEATURE_CORE_CSTATES_MASK (1 << FEATURE_CORE_CSTATES_BIT)
/* Workload bits */
-#define WORKLOAD_DEFAULT_BIT 0
-#define WORKLOAD_PPLIB_FULL_SCREEN_3D_BIT 1
-#define WORKLOAD_PPLIB_POWER_SAVING_BIT 2
-#define WORKLOAD_PPLIB_VIDEO_BIT 3
-#define WORKLOAD_PPLIB_VR_BIT 4
-#define WORKLOAD_PPLIB_COMPUTE_BIT5
-#define WORKLOAD_PPLIB_CUSTOM_BIT 6
-#define WORKLOAD_PPLIB_COUNT 7
+#define WORKLOAD_PPLIB_FULL_SCREEN_3D_BIT 0
+#define WORKLOAD_PPLIB_VIDEO_BIT 2
+#define WORKLOAD_PPLIB_VR_BIT 3
+#define WORKLOAD_PPLIB_COMPUTE_BIT4
+#define WORKLOAD_PPLIB_CUSTOM_BIT 5
+#define WORKLOAD_PPLIB_COUNT 6
typedef struct {
/* MP1_EXT_SCRATCH0 */
diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.c
b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.c
index 04226b1544e4..e57e64bbacdc 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.c
@@ -1298,15 +1298,9 @@ static int conv_power_profile_to_pplib_workload(int
power_profile)
int pplib_workload = 0;
switch (power_profile) {
- case PP_SMC_POWER_PROFILE_BOOTUP_DEFAULT:
- pplib_workload = WORKLOAD_DEFAULT_BIT;
- break;
case PP_SMC_POWER_PROFILE_FULLSCREEN3D:
pplib_workload = WORKLOAD_PPLIB_FULL_SCREEN_3D_BIT;
break;
- case PP_SMC_POWER_PROFILE_POWERSAVING:
- pplib_workload = WORKLOAD_PPLIB_POWER_SAVING_BIT;
- break;
case PP_SMC_POWER_PROFILE_VIDEO:
pplib_workload = WORKLOAD_PPLIB_VIDEO_BIT;
break;
@@ -1316,6 +1310,9 @@ static int conv_power_profile_to_pplib_workload(int
power_profile)
case PP_SMC_POWER_PROFILE_COMPUTE:
pplib_workload = WORKLOAD_PPLIB_COMPUTE_BIT;
break;
+ case PP_SMC_POWER_PROFILE_CUSTOM:
+ pplib_workload = WORKLOAD_PPLIB_CUSTOM_BIT;
+ break;
}
return pplib_workload;
--
2.17.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfxdata=04%7C01%7Calexander.deucher%40amd.com%7C2f57b9a4012a424d574908d89be7299b%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637430764514589029%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=OWntFjcijTjJa0Qrsi7YTvrEWQcIXM8dHsXxhOaKsng%3Dreserved=0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amd/display: Drop unnecessary function call
[AMD Official Use Only - Internal Distribution Only]
Reviewed-by: Alex Deucher
From: amd-gfx on behalf of Rodrigo
Siqueira
Sent: Monday, December 7, 2020 5:55 PM
To: Wentland, Harry ; Kazlauskas, Nicholas
; Pillai, Aurabindo
Cc: amd-gfx@lists.freedesktop.org
Subject: [PATCH] drm/amd/display: Drop unnecessary function call
After refactor our amdgpu_dm_atomic_commit, this function only invoke
drm_atomic_helper_commit. For this reason, this commit drops
amdgpu_dm_atomic_commit and add drm_atomic_helper_commit directly in the
atomic_commit hook.
Signed-off-by: Rodrigo Siqueira
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c| 16 +---
1 file changed, 1 insertion(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index a37948f2e596..c89066b1c471 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -2212,7 +2212,7 @@ static const struct drm_mode_config_funcs
amdgpu_dm_mode_funcs = {
.get_format_info = amd_get_format_info,
.output_poll_changed = drm_fb_helper_output_poll_changed,
.atomic_check = amdgpu_dm_atomic_check,
- .atomic_commit = amdgpu_dm_atomic_commit,
+ .atomic_commit = drm_atomic_helper_commit,
};
static struct drm_mode_config_helper_funcs amdgpu_dm_mode_config_helperfuncs =
{
@@ -8158,20 +8158,6 @@ static void amdgpu_dm_crtc_copy_transient_flags(struct
drm_crtc_state *crtc_stat
stream_state->mode_changed = drm_atomic_crtc_needs_modeset(crtc_state);
}
-static int amdgpu_dm_atomic_commit(struct drm_device *dev,
- struct drm_atomic_state *state,
- bool nonblock)
-{
- /*
-* Add check here for SoC's that support hardware cursor plane, to
-* unset legacy_cursor_update
-*/
-
- return drm_atomic_helper_commit(dev, state, nonblock);
-
- /*TODO Handle EINTR, reenable IRQ*/
-}
-
/**
* amdgpu_dm_atomic_commit_tail() - AMDgpu DM's commit tail implementation.
* @state: The atomic state to commit
--
2.29.2
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfxdata=04%7C01%7Calexander.deucher%40amd.com%7Cbbf5c6ea7e2f4e32d50d08d89b033b75%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637429785490973923%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=V5Wg2XgI9zUCTH0OhTSr3Oky8PTvy8XYIa3eAhVDnlk%3Dreserved=0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 14/17] drm/amd/display: Enable gpu_vm_support for dcn3.01
[AMD Official Use Only - Internal Distribution Only] We've dropped the CONFIG_DRM_AMD_DC_DCN3* kconfig options recently. Alex From: amd-gfx on behalf of Eryk Brol Sent: Friday, December 4, 2020 4:28 PM To: amd-gfx@lists.freedesktop.org Cc: Liu, Charlene ; Brol, Eryk ; Li, Sun peng (Leo) ; Wentland, Harry ; Zhuo, Qingqing ; Siqueira, Rodrigo ; Pillai, Aurabindo ; Sun, Yongqiang ; Lakha, Bhawanpreet ; R, Bindu Subject: [PATCH 14/17] drm/amd/display: Enable gpu_vm_support for dcn3.01 From: Charlene Liu [Why] dcn3_01 supports gpu_vm, but this is not enabled in amdgpu_dm Signed-off-by: Charlene Liu Reviewed-by: Yongqiang Sun Acked-by: Eryk Brol --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 + 1 file changed, 5 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 59f738008734..53a7cb21f603 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -1035,6 +1035,11 @@ static int amdgpu_dm_init(struct amdgpu_device *adev) if (ASICREV_IS_GREEN_SARDINE(adev->external_rev_id)) init_data.flags.disable_dmcu = true; break; +#if defined(CONFIG_DRM_AMD_DC_DCN3_01) + case CHIP_VANGOGH: + init_data.flags.gpu_vm_support = true; + break; +#endif default: break; } -- 2.25.1 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfxdata=04%7C01%7Calexander.deucher%40amd.com%7C93575bd3247e42f848bc08d8989bee3e%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637427142787650359%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=wf2Tl4Qz9IzTZVvfBRYcFHZ8Cr464ZEZ%2B1Pb1GP5W9E%3Dreserved=0 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] tests/amdgpu: Fix a typo
[AMD Official Use Only - Internal Distribution Only] Reviewed-by: Alex Deucher libdrm uses gitlab MRs now: https://gitlab.freedesktop.org/mesa/drm/-/merge_requests Alex From: Tuikov, Luben Sent: Monday, November 30, 2020 5:12 PM To: amd-gfx@lists.freedesktop.org Cc: Deucher, Alexander ; Tuikov, Luben Subject: [PATCH] tests/amdgpu: Fix a typo Fix a typo: "TZM" --> "TMZ" Signed-off-by: Luben Tuikov --- tests/amdgpu/security_tests.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/amdgpu/security_tests.c b/tests/amdgpu/security_tests.c index 9b39e167..351eac82 100644 --- a/tests/amdgpu/security_tests.c +++ b/tests/amdgpu/security_tests.c @@ -172,7 +172,7 @@ static void amdgpu_sdma_nop(uint32_t *packet, uint32_t nop_count) } /** - * amdgpu_bo_lcopy -- linear copy with TZM set, using sDMA + * amdgpu_bo_lcopy -- linear copy with TMZ set, using sDMA * @dev: AMDGPU device to which both buffer objects belong to * @dst: destination buffer object * @src: source buffer object -- 2.29.2.404.ge67fbf927d ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH v3] drm/amd/amdgpu: set the default value of noretry to 1 for some dGPUs
[AMD Public Use]
We need to figure out what the root cause is then. If we can't figure it out
soon, we should revert the change for navi1x and continue to debug it until we
can find the root cause and we can safely re-enable it.
Alex
From: Chen, Guchun
Sent: Sunday, November 29, 2020 2:22 AM
To: Bas Nieuwenhuizen ; Kuehling, Felix
Cc: Gui, Jack ; Zhou1, Tao ; amd-gfx
mailing list ; Huang, Ray ;
Deucher, Alexander ; Zhang, Hawking
Subject: RE: [PATCH v3] drm/amd/amdgpu: set the default value of noretry to 1
for some dGPUs
[AMD Public Use]
Hi Bas Nieuwenhuizen,
I don't think direct revert is one right approach, though it's able to fix your
problem. noretry=0 will cause other test failure on several ASICs.
Regards,
Guchun
-Original Message-
From: amd-gfx On Behalf Of Bas
Nieuwenhuizen
Sent: Sunday, November 29, 2020 8:38 AM
To: Kuehling, Felix
Cc: Gui, Jack ; Chen, Guchun ; Zhou1,
Tao ; amd-gfx mailing list ;
Huang, Ray ; Deucher, Alexander ;
Zhang, Hawking
Subject: Re: [PATCH v3] drm/amd/amdgpu: set the default value of noretry to 1
for some dGPUs
Can we revert this patch to fix
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fdrm%2Famd%2F-%2Fissues%2F1374data=04%7C01%7Cguchun.chen%40amd.com%7C6d626e2a3bae4877024f08d893ff15db%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637422071085800476%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Jxa2V1TuszoBKtF%2FPbIA3YwOrXHgLreBY%2FXej1HTZ4k%3Dreserved=0
?
On Thu, Oct 15, 2020 at 4:30 PM Felix Kuehling wrote:
>
> Am 2020-10-14 um 11:35 p.m. schrieb Chengming Gui:
> > noretry = 0 cause some dGPU's kfd page fault tests fail, so set
> > noretry to 1 for these special ASICs:
> > vega20/navi10/navi14/ARCTURUS
> >
> > v2: merge raven and default case due to the same setting
> > v3: remove ARCTURUS
> >
> > Signed-off-by: Chengming Gui
> > Change-Id: I3be70f463a49b0cd5c56456431d6c2cb98b13872
>
> Acked-by: Felix Kuhling
>
>
> > ---
> > drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 23
> > +++
> > 1 file changed, 15 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
> > index 36604d751d62..f26eb4e54b12 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
> > @@ -425,20 +425,27 @@ void amdgpu_gmc_noretry_set(struct amdgpu_device
> > *adev)
> > struct amdgpu_gmc *gmc = >gmc;
> >
> > switch (adev->asic_type) {
> > - case CHIP_RAVEN:
> > - /* Raven currently has issues with noretry
> > - * regardless of what we decide for other
> > - * asics, we should leave raven with
> > - * noretry = 0 until we root cause the
> > - * issues.
> > + case CHIP_VEGA20:
> > + case CHIP_NAVI10:
> > + case CHIP_NAVI14:
> > + /*
> > + * noretry = 0 will cause kfd page fault tests fail
> > + * for some ASICs, so set default to 1 for these ASICs.
> >*/
> > if (amdgpu_noretry == -1)
> > - gmc->noretry = 0;
> > + gmc->noretry = 1;
> > else
> > gmc->noretry = amdgpu_noretry;
> > break;
> > + case CHIP_RAVEN:
> > default:
> > - /* default this to 0 for now, but we may want
> > + /* Raven currently has issues with noretry
> > + * regardless of what we decide for other
> > + * asics, we should leave raven with
> > + * noretry = 0 until we root cause the
> > + * issues.
> > + *
> > + * default this to 0 for now, but we may want
> >* to change this in the future for certain
> >* GPUs as it can increase performance in
> >* certain cases.
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> s.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfxdata=04%7C01%7Cgu
> chun.chen%40amd.com%7C6d626e2a3bae4877024f08d893ff15db%7C3dd8961fe4884
> e608e11a82d994e183d%7C0%7C0%7C637422071085800476%7CUnknown%7CTWFpbGZsb
> 3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
> 7C1000sdata=VFqegGwPCj10q3Y5BdZsVq2a%2B4
Re: [PATCH] drm/amd/display: Avoid HDCP initialization in devices without output
[AMD Official Use Only - Internal Distribution Only]
Acked-by: Alex Deucher
From: Siqueira, Rodrigo
Sent: Friday, November 20, 2020 8:59 AM
To: amd-gfx@lists.freedesktop.org
Cc: Wentland, Harry ; Deucher, Alexander
Subject: [PATCH] drm/amd/display: Avoid HDCP initialization in devices without
output
The HDCP feature requires at least one connector attached to the device;
however, some GPUs do not have a physical output, making the HDCP
initialization irrelevant. This patch disables HDCP initialization when
the graphic card does not have output.
Signed-off-by: Rodrigo Siqueira
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 1da4ad529309..e213246e3f04 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -1109,7 +1109,7 @@ static int amdgpu_dm_init(struct amdgpu_device *adev)
amdgpu_dm_init_color_mod();
#ifdef CONFIG_DRM_AMD_DC_HDCP
- if (adev->asic_type >= CHIP_RAVEN) {
+ if (adev->dm.dc->caps.max_links > 0 && adev->asic_type >= CHIP_RAVEN) {
adev->dm.hdcp_workqueue = hdcp_create_workqueue(adev,
_params.cp_psp, adev->dm.dc);
if (!adev->dm.hdcp_workqueue)
--
2.29.2
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amd/pm: support runtime PPTable update for dimgrey_cavefish
[AMD Official Use Only - Internal Distribution Only] Acked-by: Alex Deucher From: amd-gfx on behalf of Tao Zhou Sent: Tuesday, November 17, 2020 2:32 AM To: Chen, Jiansong (Simon) ; Gui, Jack ; Zhang, Hawking ; amd-gfx@lists.freedesktop.org Cc: Zhou1, Tao Subject: [PATCH] drm/amd/pm: support runtime PPTable update for dimgrey_cavefish There is no need to reset DPM for PPTable uploading on dimgrey_cavefish and PMFW can handle it, same as navy_flounder. Signed-off-by: Tao Zhou --- drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c index 1904df5a3e20..8e3e7a5bbffe 100644 --- a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c +++ b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c @@ -1183,7 +1183,7 @@ static int smu_disable_dpms(struct smu_context *smu) */ if (smu->uploading_custom_pp_table && (adev->asic_type >= CHIP_NAVI10) && - (adev->asic_type <= CHIP_NAVY_FLOUNDER)) + (adev->asic_type <= CHIP_DIMGREY_CAVEFISH)) return 0; /* -- 2.17.1 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfxdata=04%7C01%7Calexander.deucher%40amd.com%7C8cf0d1af536d4d6349bc08d88acb08f2%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637411951942273028%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=UuQ66twRM2QL%2FTXOhEmkjfHH28p96lfLfL5qxJeQG9s%3Dreserved=0 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 2/2] drm/amd/pm: fix the crash after runtime pm resume
[AMD Official Use Only - Internal Distribution Only]
Series is:
Reviewed-by: Alex Deucher
Does the same thing need to be applied to navy flounder and dimgrey cavefish?
Alex
From: amd-gfx on behalf of Kenneth Feng
Sent: Tuesday, November 17, 2020 8:30 AM
To: amd-gfx@lists.freedesktop.org
Cc: Feng, Kenneth
Subject: [PATCH 2/2] drm/amd/pm: fix the crash after runtime pm resume
Some features are still disabled after runtime pm resume. This can take the
hardware back.
Unlike other projects, this doesn't need pptable retransfer.
Signed-off-by: Kenneth Feng
---
drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
index 39990790ed67..ebd50f144c5d 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
@@ -914,11 +914,14 @@ static int smu_smc_hw_setup(struct smu_context *smu)
{
struct amdgpu_device *adev = smu->adev;
uint32_t pcie_gen = 0, pcie_width = 0;
- int ret;
+ int ret = 0;
if (adev->in_suspend && smu_is_dpm_running(smu)) {
dev_info(adev->dev, "dpm has been enabled\n");
- return 0;
+ /* this is needed specifically */
+ if (adev->asic_type == CHIP_SIENNA_CICHLID)
+ ret = smu_system_features_control(smu, true);
+ return ret;
}
ret = smu_init_display_count(smu, 0);
--
2.17.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfxdata=04%7C01%7Calexander.deucher%40amd.com%7Cdd553fd04f0f44ebf3ca08d88afd11ad%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637412166838877500%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=swZeNMubEey64ZdWb7W5sTg88as3VNS9ILwmLb08GHY%3Dreserved=0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amd/pm: retire dimgrey_cavefish hardcode for the use of soft PTable
[AMD Official Use Only - Internal Distribution Only]
Acked-by: Alex Deucher
From: amd-gfx on behalf of Tao Zhou
Sent: Monday, November 16, 2020 10:31 PM
To: Chen, Jiansong (Simon) ; Gui, Jack
; Zhang, Hawking ;
amd-gfx@lists.freedesktop.org
Cc: Zhou1, Tao
Subject: [PATCH] drm/amd/pm: retire dimgrey_cavefish hardcode for the use of
soft PTable
The PPTable provided by VBIOS can be used.
Signed-off-by: Tao Zhou
---
drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c
b/drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c
index b23311096467..d5fa0d9dd7eb 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c
@@ -339,8 +339,7 @@ int smu_v11_0_setup_pptable(struct smu_context *smu)
hdr = (const struct smc_firmware_header_v1_0 *)
adev->pm.fw->data;
version_major = le16_to_cpu(hdr->header.header_version_major);
version_minor = le16_to_cpu(hdr->header.header_version_minor);
- if ((version_major == 2 &&
smu->smu_table.boot_values.pp_table_id > 0) ||
- adev->asic_type == CHIP_DIMGREY_CAVEFISH) {
+ if (version_major == 2 &&
smu->smu_table.boot_values.pp_table_id > 0) {
dev_info(adev->dev, "use driver provided pptable
%d\n", smu->smu_table.boot_values.pp_table_id);
switch (version_minor) {
case 0:
--
2.17.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfxdata=04%7C01%7Calexander.deucher%40amd.com%7Cccfce44c5e5843177c7a08d88aa95ec3%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637411807349472302%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=8bUpARFZbEDD9hF2ksu32HtFV6BdQTkPcYxMlFR33rM%3Dreserved=0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 2/2] drm/amdgpu: Enable TA firmware loading for dimgrey_cavefish
[AMD Official Use Only - Internal Distribution Only]
Series is:
Reviewed-by: Alex Deucher
From: Bhawanpreet Lakha
Sent: Wednesday, November 11, 2020 6:04 PM
To: Deucher, Alexander ; Clements, John
Cc: Kazlauskas, Nicholas ;
amd-gfx@lists.freedesktop.org ; Lakha,
Bhawanpreet
Subject: [PATCH 2/2] drm/amdgpu: Enable TA firmware loading for dimgrey_cavefish
Signed-off-by: Bhawanpreet Lakha
---
drivers/gpu/drm/amd/amdgpu/psp_v11_0.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
b/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
index 03e88dbf92be..edd2d6bd1d86 100644
--- a/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
@@ -62,7 +62,7 @@ MODULE_FIRMWARE("amdgpu/navy_flounder_ta.bin");
MODULE_FIRMWARE("amdgpu/vangogh_asd.bin");
MODULE_FIRMWARE("amdgpu/vangogh_toc.bin");
MODULE_FIRMWARE("amdgpu/dimgrey_cavefish_sos.bin");
-MODULE_FIRMWARE("amdgpu/dimgrey_cavefish_asd.bin");
+MODULE_FIRMWARE("amdgpu/dimgrey_cavefish_ta.bin");
/* address block */
#define smnMP1_FIRMWARE_FLAGS 0x3010024
@@ -192,15 +192,11 @@ static int psp_v11_0_init_microcode(struct psp_context
*psp)
break;
case CHIP_SIENNA_CICHLID:
case CHIP_NAVY_FLOUNDER:
+ case CHIP_DIMGREY_CAVEFISH:
err = psp_init_sos_microcode(psp, chip_name);
if (err)
return err;
- err = psp_init_ta_microcode(>psp, chip_name);
- if (err)
- return err;
- break;
- case CHIP_DIMGREY_CAVEFISH:
- err = psp_init_sos_microcode(psp, chip_name);
+ err = psp_init_ta_microcode(psp, chip_name);
if (err)
return err;
break;
--
2.25.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu: add UMC to ip discovery map
[AMD Official Use Only - Internal Distribution Only] Are there any other IP mappings that are missing? Maybe just add them all to avoid problems if there are other IPs we need to access in the future. Alex From: amd-gfx on behalf of Clements, John Sent: Wednesday, November 11, 2020 3:53 AM To: amd-gfx@lists.freedesktop.org ; Zhang, Hawking Subject: [PATCH] drm/amdgpu: add UMC to ip discovery map [AMD Official Use Only - Internal Distribution Only] Submitting patch to add UMC into IP discovery mapping. Thank you, John Clements ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 2/2] drm/amd/pm: update the swSMU headers for vangogh
[AMD Official Use Only - Internal Distribution Only]
Series is:
Reviewed-by: Alex Deucher
From: Du, Xiaojian
Sent: Tuesday, November 10, 2020 10:04 PM
To: amd-gfx@lists.freedesktop.org
Cc: Huang, Ray ; Huang, Shimmer ;
Quan, Evan ; Deucher, Alexander ;
Du, Xiaojian
Subject: [PATCH 2/2] drm/amd/pm: update the swSMU headers for vangogh
This patch is to update the swSMU headers for vangogh.
Signed-off-by: Xiaojian Du
Reviewed-by: Huang Rui
Reviewed-by: Evan Quan
---
drivers/gpu/drm/amd/pm/inc/smu11_driver_if_vangogh.h | 6 ++
drivers/gpu/drm/amd/pm/inc/smu_v11_5_pmfw.h | 11 +++
drivers/gpu/drm/amd/pm/inc/smu_v11_5_ppsmc.h | 11 +--
3 files changed, 22 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/inc/smu11_driver_if_vangogh.h
b/drivers/gpu/drm/amd/pm/inc/smu11_driver_if_vangogh.h
index 8f438c80132e..1c19eae93ff1 100644
--- a/drivers/gpu/drm/amd/pm/inc/smu11_driver_if_vangogh.h
+++ b/drivers/gpu/drm/amd/pm/inc/smu11_driver_if_vangogh.h
@@ -142,6 +142,12 @@ typedef struct {
uint8_t NumDfPstatesEnabled;
uint8_t NumDpmLevelsEnabled;
+ uint8_t NumDcfclkLevelsEnabled;
+ uint8_t NumDispClkLevelsEnabled; //applies to both dispclk and dppclk
+ uint8_t NumSocClkLevelsEnabled;
+
+ uint8_t IspClkLevelsEnabled; //applies to both ispiclk and ispxclk
+ uint8_t VcnClkLevelsEnabled; //applies to both vclk/dclk
uint8_t spare[2];
} DpmClocks_t;
diff --git a/drivers/gpu/drm/amd/pm/inc/smu_v11_5_pmfw.h
b/drivers/gpu/drm/amd/pm/inc/smu_v11_5_pmfw.h
index 99a406984135..22edd88b8117 100644
--- a/drivers/gpu/drm/amd/pm/inc/smu_v11_5_pmfw.h
+++ b/drivers/gpu/drm/amd/pm/inc/smu_v11_5_pmfw.h
@@ -90,14 +90,16 @@
#define FEATURE_ATHUB_PG_BIT 56
#define FEATURE_ECO_DEEPCSTATE_BIT57
#define FEATURE_CC6_BIT 58
-#define NUM_FEATURES 59
+#define FEATURE_GFX_EDC_BIT 59
+#define NUM_FEATURES 60
typedef struct {
// MP1_EXT_SCRATCH0
uint32_t DpmHandlerID : 8;
uint32_t ActivityMonitorID: 8;
uint32_t DpmTimerID : 8;
- uint32_t spare0 : 8;
+ uint32_t DpmHubID : 4;
+ uint32_t DpmHubTask : 4;
// MP1_EXT_SCRATCH1
uint32_t GfxStatus: 2;
uint32_t GfxoffStatus : 8;
@@ -109,9 +111,10 @@ typedef struct {
uint32_t spare1 : 16;
// MP1_EXT_SCRATCH2
uint32_t P2JobHandler: 32;
- // MP1_EXT_SCRATCH3
-// uint32_t spare2 : 32;
+ // MP1_EXT_SCRATCH3: used for postcodes
+
// MP1_EXT_SCRATCH4:6 are used by Kernel
+ // MP1_EXT_SCRATCH7: used by HW
} FwStatus_t;
diff --git a/drivers/gpu/drm/amd/pm/inc/smu_v11_5_ppsmc.h
b/drivers/gpu/drm/amd/pm/inc/smu_v11_5_ppsmc.h
index 1ada0eb64663..7e69b3bd311b 100644
--- a/drivers/gpu/drm/amd/pm/inc/smu_v11_5_ppsmc.h
+++ b/drivers/gpu/drm/amd/pm/inc/smu_v11_5_ppsmc.h
@@ -97,9 +97,16 @@
#define PPSMC_MSG_StopDramLogging 0x3F
#define PPSMC_MSG_SetSoftMinCclk 0x40
#define PPSMC_MSG_SetSoftMaxCclk 0x41
-#define PPSMC_Message_Count0x42
+#define PPSMC_MSG_SetDfPstateActiveLevel 0x42
+#define PPSMC_MSG_SetDfPstateSoftMinLevel 0x43
+#define PPSMC_MSG_SetCclkPolicy0x44
+#define PPSMC_MSG_DramLogSetDramAddrHigh 0x45
+#define PPSMC_MSG_DramLogSetDramBufferSize 0x46
+#define PPSMC_MSG_RequestActiveWgp 0x47
+#define PPSMC_MSG_QueryActiveWgp 0x48
+#define PPSMC_Message_Count0x49
-//Argument for PPSMC_MSG_GpuChangeState
+//Argument for PPSMC_MSG_GfxDeviceDriverReset
enum {
MODE1_RESET = 1,
MODE2_RESET = 2
--
2.17.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amd/display: Fix memory leaks in S3 resume
[AMD Official Use Only - Internal Distribution Only] Ah, sorry, I missed that part of the patch. Alex From: Wentland, Harry Sent: Tuesday, November 10, 2020 11:42 AM To: Deucher, Alexander ; Wang, Chao-kai (Stylon) ; amd-gfx@lists.freedesktop.org Cc: Kazlauskas, Nicholas Subject: Re: [PATCH] drm/amd/display: Fix memory leaks in S3 resume It's missing the "drm_connector_list_update" call which I assume is important. Stylon, can you review Lee Starnes's patch? Is the drm_connector_list_update call maybe not needed? Thanks, Harry On 2020-11-10 11:26 a.m., Deucher, Alexander wrote: [AMD Official Use Only - Internal Distribution Only] Lee Starnes just sent the exact same patch yesterday. Please review that one: https://patchwork.freedesktop.org/patch/399497/ Alex From: Wentland, Harry <mailto:harry.wentl...@amd.com> Sent: Tuesday, November 10, 2020 9:27 AM To: Wang, Chao-kai (Stylon) <mailto:stylon.w...@amd.com>; amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org> <mailto:amd-gfx@lists.freedesktop.org> Cc: Kazlauskas, Nicholas <mailto:nicholas.kazlaus...@amd.com>; Deucher, Alexander <mailto:alexander.deuc...@amd.com> Subject: Re: [PATCH] drm/amd/display: Fix memory leaks in S3 resume On 2020-11-10 2:49 a.m., Stylon Wang wrote: > EDID parsing in S3 resume pushes new display modes > to probed_modes list but doesn't consolidate to actual > mode list. This creates a race condition when > amdgpu_dm_connector_ddc_get_modes() re-initializes the > list head without walking the list and results in memory leak. > > Signed-off-by: Stylon Wang <mailto:stylon.w...@amd.com> Looks reasonable to me but haven't had a chance to understand whether this is the best solution. Acked-by: Harry Wentland <mailto:harry.wentl...@amd.com> Harry > --- > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > index 0b6adf23d316..715e0bd489f8 100644 > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > @@ -2337,7 +2337,8 @@ void amdgpu_dm_update_connector_after_detect( > >drm_connector_update_edid_property(connector, > aconnector->edid); > - drm_add_edid_modes(connector, aconnector->edid); > + aconnector->num_modes = drm_add_edid_modes(connector, > aconnector->edid); > + drm_connector_list_update(connector); > >if (aconnector->dc_link->aux_mode) >drm_dp_cec_set_edid(>dm_dp_aux.aux, > ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amd/display: Fix memory leaks in S3 resume
[AMD Official Use Only - Internal Distribution Only] Lee Starnes just sent the exact same patch yesterday. Please review that one: https://patchwork.freedesktop.org/patch/399497/ Alex From: Wentland, Harry Sent: Tuesday, November 10, 2020 9:27 AM To: Wang, Chao-kai (Stylon) ; amd-gfx@lists.freedesktop.org Cc: Kazlauskas, Nicholas ; Deucher, Alexander Subject: Re: [PATCH] drm/amd/display: Fix memory leaks in S3 resume On 2020-11-10 2:49 a.m., Stylon Wang wrote: > EDID parsing in S3 resume pushes new display modes > to probed_modes list but doesn't consolidate to actual > mode list. This creates a race condition when > amdgpu_dm_connector_ddc_get_modes() re-initializes the > list head without walking the list and results in memory leak. > > Signed-off-by: Stylon Wang Looks reasonable to me but haven't had a chance to understand whether this is the best solution. Acked-by: Harry Wentland Harry > --- > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > index 0b6adf23d316..715e0bd489f8 100644 > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > @@ -2337,7 +2337,8 @@ void amdgpu_dm_update_connector_after_detect( > >drm_connector_update_edid_property(connector, > aconnector->edid); > - drm_add_edid_modes(connector, aconnector->edid); > + aconnector->num_modes = drm_add_edid_modes(connector, > aconnector->edid); > + drm_connector_list_update(connector); > >if (aconnector->dc_link->aux_mode) >drm_dp_cec_set_edid(>dm_dp_aux.aux, > ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu: enable DCN for navi10 headless SKU
[AMD Official Use Only - Internal Distribution Only] Reviewed-by: Alex Deucher From: amd-gfx on behalf of Tianci Yin Sent: Friday, November 6, 2020 2:36 AM To: amd-gfx@lists.freedesktop.org Cc: Long, Gang ; Chen, Guchun ; Xu, Feifei ; Yin, Tianci (Rico) ; Tuikov, Luben ; Deucher, Alexander ; Cui, Flora ; Zhang, Hawking Subject: [PATCH] drm/amdgpu: enable DCN for navi10 headless SKU From: "Tianci.Yin" There is a NULL pointer crash when DCN disabled on headless SKU. On normal SKU, the variable adev->ddev.mode_config.funcs is initialized in dm_hw_init(), and it is fine to access it in amdgpu_device_resume(). But on headless SKU, DCN is disabled, the funcs variable is not initialized, then crash arises. Enable DCN to fix this issue. Change-Id: I33bc30210e3420e60ceb59175e39855d00b05b06 Signed-off-by: Tianci.Yin --- drivers/gpu/drm/amd/amdgpu/nv.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/nv.c b/drivers/gpu/drm/amd/amdgpu/nv.c index e33d8022cc32..67375b2948f5 100644 --- a/drivers/gpu/drm/amd/amdgpu/nv.c +++ b/drivers/gpu/drm/amd/amdgpu/nv.c @@ -535,8 +535,7 @@ int nv_set_ip_blocks(struct amdgpu_device *adev) if (adev->enable_virtual_display || amdgpu_sriov_vf(adev)) amdgpu_device_ip_block_add(adev, _virtual_ip_block); #if defined(CONFIG_DRM_AMD_DC) - else if (amdgpu_device_has_dc_support(adev) && -!nv_is_headless_sku(adev->pdev)) + else if (amdgpu_device_has_dc_support(adev)) amdgpu_device_ip_block_add(adev, _ip_block); #endif amdgpu_device_ip_block_add(adev, _v10_0_ip_block); -- 2.25.1 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfxdata=04%7C01%7Calexander.deucher%40amd.com%7C516e3593f84a45811bd908d88226c8e8%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637402450426333203%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=RzbVAu02p9LVSSOXx3M0QwQztABgpf8FRiWhDyU6BOY%3Dreserved=0 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu: Fix Arcturus fan speed reporting
[AMD Official Use Only - Internal Distribution Only]
Acked-by: Alex Deucher
From: amd-gfx on behalf of Kent Russell
Sent: Thursday, November 5, 2020 10:20 AM
To: amd-gfx@lists.freedesktop.org
Cc: Russell, Kent
Subject: [PATCH] drm/amdgpu: Fix Arcturus fan speed reporting
Arcturus doesn't have a fan. The assumption of "if the manual fan
control bit isn't set, it's on automatic mode" does not hold true if the
fan is missing, and results in exposing an invalid value for fan speed.
The SMU metrics table accurately reflects the lack of fan and will
return 0 for the fan speed. Trying to use the
smu_v11_0_get_fan_speed_rpm function will return invalid data, so just
stick with the SMU metrics for Arcturus
Signed-off-by: Kent Russell
---
drivers/gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c
b/drivers/gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c
index d96048e98237..4fd850e58004 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c
@@ -1139,14 +1139,9 @@ static int arcturus_get_fan_speed_rpm(struct smu_context
*smu,
if (!speed)
return -EINVAL;
- switch (smu_v11_0_get_fan_control_mode(smu)) {
- case AMD_FAN_CTRL_AUTO:
- return arcturus_get_smu_metrics_data(smu,
-METRICS_CURR_FANSPEED,
-speed);
- default:
- return smu_v11_0_get_fan_speed_rpm(smu, speed);
- }
+ return arcturus_get_smu_metrics_data(smu,
+METRICS_CURR_FANSPEED,
+speed);
}
static int arcturus_get_fan_parameters(struct smu_context *smu)
--
2.17.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfxdata=04%7C01%7Calexander.deucher%40amd.com%7Cc266d21dcb5e4d84073808d8819e9820%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637401865460755885%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=O8kmXHVEGi01B7S0gk5MPafIEiuBC9v7catH%2FASo6iQ%3Dreserved=0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu: clip the ref divider max value at 100
yeah, ideally. Just need to get support for analog encoders. Alex From: Koenig, Christian Sent: Wednesday, November 4, 2020 9:31 AM To: Deucher, Alexander ; Sharma, Shashank ; amd-gfx@lists.freedesktop.org Cc: Qin, Eddy Subject: Re: [PATCH] drm/amdgpu: clip the ref divider max value at 100 In the long term we probably want to nuke this code anyway and switch to the DC code, don't we? Christian. Am 04.11.20 um 15:23 schrieb Deucher, Alexander: You might want to talk to the DAL team, they may have some advice. In general, I would say test it as well as you can. It's probably safe as radeon is still the default driver for SI parts and generally seems to be working well there. Alex From: Sharma, Shashank <mailto:shashank.sha...@amd.com> Sent: Wednesday, November 4, 2020 9:11 AM To: Deucher, Alexander <mailto:alexander.deuc...@amd.com>; Koenig, Christian <mailto:christian.koe...@amd.com>; amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org> <mailto:amd-gfx@lists.freedesktop.org> Cc: Qin, Eddy <mailto:eddy@amd.com> Subject: Re: [PATCH] drm/amdgpu: clip the ref divider max value at 100 Thanks Alex, Same question here, Should we go through some extensive test routine due to change in PLL values, or is it OK to go ahead based on our experience from Radeon values ? Regards Shashank On 04/11/20 7:36 pm, Deucher, Alexander wrote: Acked-by: Alex Deucher <mailto:alexander.deuc...@amd.com> From: Koenig, Christian <mailto:christian.koe...@amd.com> Sent: Wednesday, November 4, 2020 6:54 AM To: Sharma, Shashank <mailto:shashank.sha...@amd.com>; amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org> <mailto:amd-gfx@lists.freedesktop.org> Cc: Deucher, Alexander <mailto:alexander.deuc...@amd.com>; Qin, Eddy <mailto:eddy@amd.com> Subject: Re: [PATCH] drm/amdgpu: clip the ref divider max value at 100 Am 04.11.20 um 11:40 schrieb Sharma, Shashank: > [AMD Public Use] > > Hello Christian, > Yes, that 100 is hardcoded in Radeon, and git blame says it was one of your > patches which made it 100 from 128 . > Would you mind having a look at commit id: > 4b21ce1b4b5d262e7d4656b8ececc891fc3cb806 ? Ah, yes that one :) Yeah the background is that this was just an educated guess because I couldn't find anybody which could tell me what the real limits of the PLL is. Looks like we just forgot to apply that patch to amdgpu. Regards, Christian. > > Regards > Shashank > -Original Message- > From: Koenig, Christian > <mailto:christian.koe...@amd.com> > Sent: Wednesday, November 4, 2020 3:35 PM > To: Sharma, Shashank > <mailto:shashank.sha...@amd.com>; > amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org> > Cc: Deucher, Alexander > <mailto:alexander.deuc...@amd.com>; Qin, Eddy > <mailto:eddy@amd.com> > Subject: Re: [PATCH] drm/amdgpu: clip the ref divider max value at 100 > > Am 03.11.20 um 18:13 schrieb Shashank Sharma: >> This patch limits the ref_div_max value to 100, during the calculation >> of PLL feedback reference divider. With current value (128), the >> produced fb_ref_div value generates unstable output at particular >> frequencies. Radeon driver limits this value at 100. > Mhm, is that 100 hard coded in radeon? I have no idea where that is coming > from. > > Best would probably to grab a hardware engineer and try to figure out what > the real maximums for the PLL is to still produce a stable signal. > > Christian. > >> On Oland, when we try to setup mode 2048x1280@60 (a bit weird, I >> know), it demands a clock of 221270 Khz. It's been observed that the >> PLL calculations using values 128 and 100 are vastly different, and >> look like this: >> >> +--+ >> |Parameter|AMDGPU|Radeon | >> | | | | >> +-++ >> |Clock feedback | | >> |divider max | 128 | 100 | >> |cap value| | | >> | | | | >> | | | | >> +--+ >> |ref_div_max | | | >> | | 42 | 20 | >> | | | | >> | | | | >> +--+ >> |ref_div | 42 | 20 | &g
Re: [PATCH] drm/amdgpu: clip the ref divider max value at 100
You might want to talk to the DAL team, they may have some advice. In general, I would say test it as well as you can. It's probably safe as radeon is still the default driver for SI parts and generally seems to be working well there. Alex From: Sharma, Shashank Sent: Wednesday, November 4, 2020 9:11 AM To: Deucher, Alexander ; Koenig, Christian ; amd-gfx@lists.freedesktop.org Cc: Qin, Eddy Subject: Re: [PATCH] drm/amdgpu: clip the ref divider max value at 100 Thanks Alex, Same question here, Should we go through some extensive test routine due to change in PLL values, or is it OK to go ahead based on our experience from Radeon values ? Regards Shashank On 04/11/20 7:36 pm, Deucher, Alexander wrote: Acked-by: Alex Deucher <mailto:alexander.deuc...@amd.com> From: Koenig, Christian <mailto:christian.koe...@amd.com> Sent: Wednesday, November 4, 2020 6:54 AM To: Sharma, Shashank <mailto:shashank.sha...@amd.com>; amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org> <mailto:amd-gfx@lists.freedesktop.org> Cc: Deucher, Alexander <mailto:alexander.deuc...@amd.com>; Qin, Eddy <mailto:eddy@amd.com> Subject: Re: [PATCH] drm/amdgpu: clip the ref divider max value at 100 Am 04.11.20 um 11:40 schrieb Sharma, Shashank: > [AMD Public Use] > > Hello Christian, > Yes, that 100 is hardcoded in Radeon, and git blame says it was one of your > patches which made it 100 from 128 . > Would you mind having a look at commit id: > 4b21ce1b4b5d262e7d4656b8ececc891fc3cb806 ? Ah, yes that one :) Yeah the background is that this was just an educated guess because I couldn't find anybody which could tell me what the real limits of the PLL is. Looks like we just forgot to apply that patch to amdgpu. Regards, Christian. > > Regards > Shashank > -Original Message- > From: Koenig, Christian > <mailto:christian.koe...@amd.com> > Sent: Wednesday, November 4, 2020 3:35 PM > To: Sharma, Shashank > <mailto:shashank.sha...@amd.com>; > amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org> > Cc: Deucher, Alexander > <mailto:alexander.deuc...@amd.com>; Qin, Eddy > <mailto:eddy@amd.com> > Subject: Re: [PATCH] drm/amdgpu: clip the ref divider max value at 100 > > Am 03.11.20 um 18:13 schrieb Shashank Sharma: >> This patch limits the ref_div_max value to 100, during the calculation >> of PLL feedback reference divider. With current value (128), the >> produced fb_ref_div value generates unstable output at particular >> frequencies. Radeon driver limits this value at 100. > Mhm, is that 100 hard coded in radeon? I have no idea where that is coming > from. > > Best would probably to grab a hardware engineer and try to figure out what > the real maximums for the PLL is to still produce a stable signal. > > Christian. > >> On Oland, when we try to setup mode 2048x1280@60 (a bit weird, I >> know), it demands a clock of 221270 Khz. It's been observed that the >> PLL calculations using values 128 and 100 are vastly different, and >> look like this: >> >> +--+ >> |Parameter|AMDGPU|Radeon | >> | | | | >> +-++ >> |Clock feedback | | >> |divider max | 128 | 100 | >> |cap value| | | >> | | | | >> | | | | >> +--+ >> |ref_div_max | | | >> | | 42 | 20 | >> | | | | >> | | | | >> +--+ >> |ref_div | 42 | 20 | >> | | | | >> +--+ >> |fb_div | 10326 | 8195 | >> +--+ >> |fb_div | 1024| 163| >> +--+ >> |fb_dev_p | 4 | 9 | >> |frac fb_de^_p| | | >> ++-+ >> >> With ref_div_max value clipped at 100, AMDGPU driver can also drive >> videmode 2048x1280@60 (221Mhz) and produce proper output without any >> blanking and distortion on the screen. >> >> PS: This value was changed from 128 to 100 in Radeon driver also, here: >> https://gith
Re: [PATCH] drm/amdgpu: clip the ref divider max value at 100
Acked-by: Alex Deucher
From: Koenig, Christian
Sent: Wednesday, November 4, 2020 6:54 AM
To: Sharma, Shashank ; amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Qin, Eddy
Subject: Re: [PATCH] drm/amdgpu: clip the ref divider max value at 100
Am 04.11.20 um 11:40 schrieb Sharma, Shashank:
> [AMD Public Use]
>
> Hello Christian,
> Yes, that 100 is hardcoded in Radeon, and git blame says it was one of your
> patches which made it 100 from 128 .
> Would you mind having a look at commit id:
> 4b21ce1b4b5d262e7d4656b8ececc891fc3cb806 ?
Ah, yes that one :)
Yeah the background is that this was just an educated guess because I
couldn't find anybody which could tell me what the real limits of the
PLL is.
Looks like we just forgot to apply that patch to amdgpu.
Regards,
Christian.
>
> Regards
> Shashank
> -Original Message-
> From: Koenig, Christian
> Sent: Wednesday, November 4, 2020 3:35 PM
> To: Sharma, Shashank ; amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Qin, Eddy
>
> Subject: Re: [PATCH] drm/amdgpu: clip the ref divider max value at 100
>
> Am 03.11.20 um 18:13 schrieb Shashank Sharma:
>> This patch limits the ref_div_max value to 100, during the calculation
>> of PLL feedback reference divider. With current value (128), the
>> produced fb_ref_div value generates unstable output at particular
>> frequencies. Radeon driver limits this value at 100.
> Mhm, is that 100 hard coded in radeon? I have no idea where that is coming
> from.
>
> Best would probably to grab a hardware engineer and try to figure out what
> the real maximums for the PLL is to still produce a stable signal.
>
> Christian.
>
>> On Oland, when we try to setup mode 2048x1280@60 (a bit weird, I
>> know), it demands a clock of 221270 Khz. It's been observed that the
>> PLL calculations using values 128 and 100 are vastly different, and
>> look like this:
>>
>> +--+
>> |Parameter|AMDGPU|Radeon |
>> | | | |
>> +-++
>> |Clock feedback | |
>> |divider max | 128 | 100 |
>> |cap value| | |
>> | | | |
>> | | | |
>> +--+
>> |ref_div_max | | |
>> | | 42 | 20 |
>> | | | |
>> | | | |
>> +--+
>> |ref_div | 42 | 20 |
>> | | | |
>> +--+
>> |fb_div | 10326 | 8195 |
>> +--+
>> |fb_div | 1024| 163|
>> +--+
>> |fb_dev_p | 4 | 9 |
>> |frac fb_de^_p| | |
>> ++-+
>>
>> With ref_div_max value clipped at 100, AMDGPU driver can also drive
>> videmode 2048x1280@60 (221Mhz) and produce proper output without any
>> blanking and distortion on the screen.
>>
>> PS: This value was changed from 128 to 100 in Radeon driver also, here:
>> https://github.com/freedesktop/drm-tip/commit/4b21ce1b4b5d262e7d4656b8
>> ececc891fc3cb806
>>
>> Cc: Alex Deucher
>> Cc: Christian König
>> Cc: Eddy Qin
>>
>> Signed-off-by: Shashank Sharma
>> ---
>>drivers/gpu/drm/amd/amdgpu/amdgpu_pll.c | 2 +-
>>1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pll.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_pll.c
>> index 1f2305b7bd13..23a2e1ebf78a 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pll.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pll.c
>> @@ -85,7 +85,7 @@ static void amdgpu_pll_get_fb_ref_div(unsigned nom,
>> unsigned den, unsigned post_
>> unsigned *fb_div, unsigned *ref_div)
>>{
>> /* limit reference * post divider to a maximum */
>> -ref_div_max = min(128 / post_div, ref_div_max);
>> +ref_div_max = min(100 / post_div, ref_div_max);
>>
>> /* get matching reference and feedback divider */
>> *ref_div = min(max(DIV_ROUND_CLOSEST(den, post_div), 1u),
>> ref_div_max);
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amd/display: fix psr panel lightup
Reviewed-by: Alex Deucher From: roman...@amd.com Sent: Tuesday, November 3, 2020 6:12 PM To: amd-gfx@lists.freedesktop.org ; Deucher, Alexander ; Quan, Evan ; Siqueira, Rodrigo ; Pillai, Aurabindo Cc: Li, Roman Subject: [PATCH] drm/amd/display: fix psr panel lightup From: Roman Li [Why] The change for correct asic type check caused a psr regression due to incorrect chip family id for Raven. [How] Use correct family id. Signed-off-by: Roman Li --- drivers/gpu/drm/amd/display/dc/core/dc_link.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c b/drivers/gpu/drm/amd/display/dc/core/dc_link.c index 6b8bc8dde6ea..09b51fca3d44 100644 --- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c @@ -2740,7 +2740,7 @@ bool dc_link_setup_psr(struct dc_link *link, #if defined(CONFIG_DRM_AMD_DC_DCN) /*skip power down the single pipe since it blocks the cstate*/ - if ((link->ctx->asic_id.chip_family == FAMILY_AI) && + if ((link->ctx->asic_id.chip_family == FAMILY_RV) && ASICREV_IS_RAVEN(link->ctx->asic_id.hw_internal_rev)) psr_context->psr_level.bits.SKIP_CRTC_DISABLE = true; #endif -- 2.17.1 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
RE: [PATCH] drm/amdgpu: do not initialise global variables to 0 or NULL
[AMD Public Use] > -Original Message- > From: Greg KH > Sent: Tuesday, November 3, 2020 1:53 AM > To: Koenig, Christian > Cc: Alex Deucher ; Deepak R Varma > ; David Airlie ; LKML ker...@vger.kernel.org>; Maling list - DRI developers de...@lists.freedesktop.org>; Melissa Wen ; > amd-gfx list ; Daniel Vetter > ; Daniel Vetter ; Deucher, > Alexander > Subject: Re: [PATCH] drm/amdgpu: do not initialise global variables to 0 or > NULL > > On Mon, Nov 02, 2020 at 09:06:21PM +0100, Christian König wrote: > > Am 02.11.20 um 20:43 schrieb Alex Deucher: > > > On Mon, Nov 2, 2020 at 1:42 PM Deepak R Varma > wrote: > > > > Initializing global variable to 0 or NULL is not necessary and > > > > should be avoided. Issue reported by checkpatch script as: > > > > ERROR: do not initialise globals to 0 (or NULL). > > > I agree that this is technically correct, but a lot of people don't > > > seem to know that so we get a lot of comments about this code for > > > the variables that are not explicitly set. Seems less confusing to > > > initialize them even if it not necessary. I don't have a > > > particularly strong opinion on it however. > > > > Agree with Alex. > > > > Especially for the module parameters we should have a explicit init > > value for documentation purposes, even when it is 0. > > Why is this one tiny driver somehow special compared to the entire rest of > the kernel? (hint, it isn't...) > > Please follow the normal coding style rules, there's no reason to ignore them > unless you like to constantly reject patches like this that get sent to you. > I'll apply the patch, but as a data point, this is the first time I've gotten a patch to make this change. I get several bug reports or patches every year to explicitly set values to global variables because users assume they are not initialized. So it will always be a trade off as to which patches you want to NACK. Alex ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu: update module paramter doc of amdgpu_dpm
Reviewed-by: Alex Deucher From: amd-gfx on behalf of Kevin Wang Sent: Tuesday, November 3, 2020 12:54 AM To: amd-gfx@lists.freedesktop.org Cc: Wang, Kevin(Yang) ; Feng, Kenneth Subject: [PATCH] drm/amdgpu: update module paramter doc of amdgpu_dpm the vega20 isn't supported swsmu. Signed-off-by: Kevin Wang --- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c index 03f4aab1fe99..9d28054b8aae 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c @@ -279,7 +279,7 @@ module_param_string(lockup_timeout, amdgpu_lockup_timeout, sizeof(amdgpu_lockup_ /** * DOC: dpm (int) * Override for dynamic power management setting - * (0 = disable, 1 = enable, 2 = enable sw smu driver for vega20) + * (0 = disable, 1 = enable) * The default is -1 (auto). */ MODULE_PARM_DESC(dpm, "DPM support (1 = enable, 0 = disable, -1 = auto)"); -- 2.17.1 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfxdata=04%7C01%7Calexander.deucher%40amd.com%7C4ae8b1a81d21425639d008d87fbcf7a4%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637399796905142189%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=fuXa0uSIEISgNh%2FUxxU3HlEDJDb9E41UGW7EouDVm5k%3Dreserved=0 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu: fix NULL pointer crash on navi10 headless SKU
That should be harmless and we can fix that up. Does everything work as expected other than the error message? Alex From: Yin, Tianci (Rico) Sent: Monday, November 2, 2020 9:51 PM To: Alex Deucher ; Deucher, Alexander Cc: Zhang, Hawking ; amd-gfx@lists.freedesktop.org ; Cui, Flora ; Xu, Feifei ; Tuikov, Luben ; Chen, Guchun ; Long, Gang Subject: Re: [PATCH] drm/amdgpu: fix NULL pointer crash on navi10 headless SKU [AMD Official Use Only - Internal Distribution Only] Hi Alex, If we don't skip DCN in nv_set_ip_blocks, I find below error, [ 103.949926] [drm:amdgpu_dm_init.cold [amdgpu]] *ERROR* amdgpu: failed to initialize hdcp_workqueue. Thanks! Rico From: Alex Deucher Sent: Tuesday, November 3, 2020 1:49 To: Deucher, Alexander Cc: Yin, Tianci (Rico) ; Zhang, Hawking ; amd-gfx@lists.freedesktop.org ; Cui, Flora ; Xu, Feifei ; Tuikov, Luben ; Chen, Guchun ; Long, Gang Subject: Re: [PATCH] drm/amdgpu: fix NULL pointer crash on navi10 headless SKU Does everything work as expected if we don't skip DCN in nv_set_ip_blocks? Alex On Mon, Nov 2, 2020 at 10:38 AM Deucher, Alexander wrote: > > [AMD Public Use] > > > That's the IP discovery table. The Object header is part of atombios. Do > you have an vbios image from that system? > > Alex > > > > From: Yin, Tianci (Rico) > Sent: Sunday, November 1, 2020 10:46 PM > To: Deucher, Alexander ; Zhang, Hawking > ; amd-gfx@lists.freedesktop.org > > Cc: Tuikov, Luben ; Chen, Guchun ; > Cui, Flora ; Xu, Feifei ; Long, Gang > > Subject: Re: [PATCH] drm/amdgpu: fix NULL pointer crash on navi10 headless SKU > > > [AMD Public Use] > > > Thanks very much Hawking! > > > Hi Alex, > > The amdgpu_device_ip_get_ip_block() depends on the adev->ip_blocks that > initialized by nv_set_ip_blocks(). > In nv_set_ip_blocks(), whether add dm_ip_block depends on > amdgpu_device_has_dc_support(). > And amdgpu_device_has_dc_support() depends on > amdgpu_device_asic_has_dc_support(), > So amdgpu_device_asic_has_dc_support() can't conditional on > amdgpu_device_ip_get_ip_block(), it makes a dependency loop. > > I have just checked the atombios object table in the headless VBIOS, and find > DCN and VCN are still there. > [ 174.815714] [drm:amdgpu_discovery_reg_base_init [amdgpu]] DMU(271) #0 > v2.0.2: > [ 174.815771] [drm:amdgpu_discovery_reg_base_init [amdgpu]] 0x0012 > [ 174.815829] [drm:amdgpu_discovery_reg_base_init [amdgpu]] 0x00c0 > [ 174.815887] [drm:amdgpu_discovery_reg_base_init [amdgpu]] 0x34c0 > [ 174.815945] [drm:amdgpu_discovery_reg_base_init [amdgpu]] 0x9000 > [ 174.816002] [drm:amdgpu_discovery_reg_base_init [amdgpu]] 0x02403c00 > [ 174.821854] [drm:amdgpu_discovery_reg_base_init [amdgpu]] UVD(12) #0 > v2.0.0: > [ 174.821908] [drm:amdgpu_discovery_reg_base_init [amdgpu]] 0x7800 > [ 174.821962] [drm:amdgpu_discovery_reg_base_init [amdgpu]] 0x7e00 > [ 174.822017] [drm:amdgpu_discovery_reg_base_init [amdgpu]] 0x02403000 > So I think DAL driver can't tell it's a normal ASIC or headless ASIC. > > Thanks! > Rico > > > From: Deucher, Alexander > Sent: Friday, October 30, 2020 22:18 > To: Zhang, Hawking ; Yin, Tianci (Rico) > ; amd-gfx@lists.freedesktop.org > > Cc: Tuikov, Luben ; Chen, Guchun ; > Cui, Flora ; Xu, Feifei ; Long, Gang > > Subject: Re: [PATCH] drm/amdgpu: fix NULL pointer crash on navi10 headless SKU > > > [AMD Public Use] > > > Maybe it would be easier to check if the DCE IP exists? E.g., > if (!amdgpu_device_ip_get_ip_block(adev, AMD_IP_BLOCK_TYPE_DCE) || > (!amdgpu_device_has_dc_support(adev)) > ... > > Also do we even need to skip DCN init for these cards, or will the display > code handle it automatically since there will be no displays in the atombios > object table. We didn't do anything special for display with the polaris > blockchain cards. > > Alex > > > From: Zhang, Hawking > Sent: Friday, October 30, 2020 9:00 AM > To: Yin, Tianci (Rico) ; amd-gfx@lists.freedesktop.org > > Cc: Tuikov, Luben ; Deucher, Alexander > ; Chen, Guchun ; Cui, Flora > ; Xu, Feifei ; Long, Gang > > Subject: RE: [PATCH] drm/amdgpu: fix NULL pointer crash on navi10 headless SKU > > > [AMD Public Use] > > > [AMD Public Use] > > > > I see, thanks for the clarifying. The patch is > > > > Reviewed-by: Hawking Zhang > > > > I was thinking to have a new flag like AMD_IS_HEADLESS in amd_chip_flag, but > after think it a bit more, that’s just complicated the case, I agree with > your curr
Re: [PATCH] amdkfd: Check kvmalloc return before memcpy
[AMD Official Use Only - Internal Distribution Only] Reviewed-by: Alex Deucher From: amd-gfx on behalf of Kent Russell Sent: Monday, November 2, 2020 11:27 AM To: amd-gfx@lists.freedesktop.org Cc: Russell, Kent Subject: [PATCH] amdkfd: Check kvmalloc return before memcpy If we can't kvmalloc the pcrat_image, then we shouldn't memcpy Signed-off-by: Kent Russell Reported-by: kernel test robot --- drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c index cdd5032d5c0e..a0acf2310357 100644 --- a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c @@ -804,10 +804,10 @@ int kfd_create_crat_image_acpi(void **crat_image, size_t *size) } pcrat_image = kvmalloc(crat_table->length, GFP_KERNEL); - memcpy(pcrat_image, crat_table, crat_table->length); if (!pcrat_image) return -ENOMEM; + memcpy(pcrat_image, crat_table, crat_table->length); *crat_image = pcrat_image; *size = crat_table->length; -- 2.17.1 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfxdata=04%7C01%7Calexander.deucher%40amd.com%7C20c8797c2a6d4fb8bf5a08d87f4c3732%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637399312636837144%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=84VCnd9ugeRKlAyqOYpXHm2PvPXUhM0gQjJd9AR95mA%3Dreserved=0 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu: fix NULL pointer crash on navi10 headless SKU
[AMD Public Use]
That's the IP discovery table. The Object header is part of atombios. Do you
have an vbios image from that system?
Alex
From: Yin, Tianci (Rico)
Sent: Sunday, November 1, 2020 10:46 PM
To: Deucher, Alexander ; Zhang, Hawking
; amd-gfx@lists.freedesktop.org
Cc: Tuikov, Luben ; Chen, Guchun ;
Cui, Flora ; Xu, Feifei ; Long, Gang
Subject: Re: [PATCH] drm/amdgpu: fix NULL pointer crash on navi10 headless SKU
[AMD Public Use]
Thanks very much Hawking!
Hi Alex,
The amdgpu_device_ip_get_ip_block() depends on the adev->ip_blocks that
initialized by nv_set_ip_blocks().
In nv_set_ip_blocks(), whether add dm_ip_block depends on
amdgpu_device_has_dc_support().
And amdgpu_device_has_dc_support() depends on
amdgpu_device_asic_has_dc_support(),
So amdgpu_device_asic_has_dc_support() can't conditional on
amdgpu_device_ip_get_ip_block(), it makes a dependency loop.
I have just checked the atombios object table in the headless VBIOS, and find
DCN and VCN are still there.
[ 174.815714] [drm:amdgpu_discovery_reg_base_init [amdgpu]] DMU(271) #0 v2.0.2:
[ 174.815771] [drm:amdgpu_discovery_reg_base_init [amdgpu]] 0x0012
[ 174.815829] [drm:amdgpu_discovery_reg_base_init [amdgpu]] 0x00c0
[ 174.815887] [drm:amdgpu_discovery_reg_base_init [amdgpu]] 0x34c0
[ 174.815945] [drm:amdgpu_discovery_reg_base_init [amdgpu]] 0x9000
[ 174.816002] [drm:amdgpu_discovery_reg_base_init [amdgpu]] 0x02403c00
[ 174.821854] [drm:amdgpu_discovery_reg_base_init [amdgpu]] UVD(12) #0 v2.0.0:
[ 174.821908] [drm:amdgpu_discovery_reg_base_init [amdgpu]] 0x7800
[ 174.821962] [drm:amdgpu_discovery_reg_base_init [amdgpu]] 0x7e00
[ 174.822017] [drm:amdgpu_discovery_reg_base_init [amdgpu]] 0x02403000
So I think DAL driver can't tell it's a normal ASIC or headless ASIC.
Thanks!
Rico
From: Deucher, Alexander
Sent: Friday, October 30, 2020 22:18
To: Zhang, Hawking ; Yin, Tianci (Rico)
; amd-gfx@lists.freedesktop.org
Cc: Tuikov, Luben ; Chen, Guchun ;
Cui, Flora ; Xu, Feifei ; Long, Gang
Subject: Re: [PATCH] drm/amdgpu: fix NULL pointer crash on navi10 headless SKU
[AMD Public Use]
Maybe it would be easier to check if the DCE IP exists? E.g.,
if (!amdgpu_device_ip_get_ip_block(adev, AMD_IP_BLOCK_TYPE_DCE) ||
(!amdgpu_device_has_dc_support(adev))
...
Also do we even need to skip DCN init for these cards, or will the display code
handle it automatically since there will be no displays in the atombios object
table. We didn't do anything special for display with the polaris blockchain
cards.
Alex
From: Zhang, Hawking
Sent: Friday, October 30, 2020 9:00 AM
To: Yin, Tianci (Rico) ; amd-gfx@lists.freedesktop.org
Cc: Tuikov, Luben ; Deucher, Alexander
; Chen, Guchun ; Cui, Flora
; Xu, Feifei ; Long, Gang
Subject: RE: [PATCH] drm/amdgpu: fix NULL pointer crash on navi10 headless SKU
[AMD Public Use]
[AMD Public Use]
I see, thanks for the clarifying. The patch is
Reviewed-by: Hawking Zhang
I was thinking to have a new flag like AMD_IS_HEADLESS in amd_chip_flag, but
after think it a bit more, that’s just complicated the case, I agree with your
current approach.
Regards,
Hawking
From: Yin, Tianci (Rico)
Sent: Friday, October 30, 2020 20:05
To: Zhang, Hawking ; amd-gfx@lists.freedesktop.org
Cc: Tuikov, Luben ; Deucher, Alexander
; Chen, Guchun ; Cui, Flora
; Xu, Feifei ; Long, Gang
Subject: Re: [PATCH] drm/amdgpu: fix NULL pointer crash on navi10 headless SKU
[AMD Public Use]
Hi Hawking,
amdgpu_device_asic_has_dc_support() is referrenced by amdgpu_pci_probe(),
at that point, adev has not been allocated yet.
My change can make it to right code path.
int amdgpu_device_resume(struct drm_device *dev, bool fbcon)
{
...
if (!amdgpu_device_has_dc_support(adev))
drm_helper_hpd_irq_event(dev); //right path for headless SKU
else
drm_kms_helper_hotplug_event(dev); //wrong path for headless SKU
...
}
Thanks!
Rico
From: Zhang, Hawking mailto:hawking.zh...@amd.com>>
Sent: Friday, October 30, 2020 19:48
To: Yin, Tianci (Rico) mailto:tianci@amd.com>>;
amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>
mailto:amd-gfx@lists.freedesktop.org>>
Cc: Tuikov, Luben mailto:luben.tui...@amd.com>>; Deucher,
Alexander mailto:alexander.deuc...@amd.com>>; Chen,
Guchun mailto:guchun.c...@amd.com>>; Cui, Flora
mailto:flora@amd.com>>; Xu, Feifei
mailto:feifei...@amd.com>>; Long, Gang
mailto:gang.l...@amd.com>>; Yin, Tianci (Rico)
mailto:tianci@amd.com>>
Subject: RE: [PATCH] drm/amdgpu: fix NULL pointer crash on navi10 headless SKU
[AMD Public Use]
I'm not sure I get your point on changing amdgpu_device_has_dc_support()
interface by adding new parameter. but it seems to me change input parameter
from
Re: [PATCH] drm/amdgpu: replace ih ip block for vega20 and arcturus
[AMD Public Use]
It might be cleaner to just split out vega20 into a separate switch case in
that function.
Alex
From: amd-gfx on behalf of Alex Sierra
Sent: Friday, October 30, 2020 11:06 PM
To: amd-gfx@lists.freedesktop.org
Cc: Sierra Guiza, Alejandro (Alex)
Subject: [PATCH] drm/amdgpu: replace ih ip block for vega20 and arcturus
[Why]
Vega20 and Arcturus asics use oss 5.0 version.
[How]
Replace ih ip block by navi10 for vega20 and arcturus.
Signed-off-by: Alex Sierra
---
drivers/gpu/drm/amd/amdgpu/soc15.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/soc15.c
b/drivers/gpu/drm/amd/amdgpu/soc15.c
index f57c5f57efa8..fc5b11752931 100644
--- a/drivers/gpu/drm/amd/amdgpu/soc15.c
+++ b/drivers/gpu/drm/amd/amdgpu/soc15.c
@@ -62,6 +62,7 @@
#include "nbio_v7_0.h"
#include "nbio_v7_4.h"
#include "vega10_ih.h"
+#include "navi10_ih.h"
#include "sdma_v4_0.h"
#include "uvd_v7_0.h"
#include "vce_v4_0.h"
@@ -734,9 +735,15 @@ int soc15_set_ip_blocks(struct amdgpu_device *adev)
else
amdgpu_device_ip_block_add(adev,
_v3_1_ip_block);
}
- amdgpu_device_ip_block_add(adev, _ih_ip_block);
+ if (adev->asic_type == CHIP_VEGA20)
+ amdgpu_device_ip_block_add(adev,
_ih_ip_block);
+ else
+ amdgpu_device_ip_block_add(adev,
_ih_ip_block);
} else {
- amdgpu_device_ip_block_add(adev, _ih_ip_block);
+ if (adev->asic_type == CHIP_VEGA20)
+ amdgpu_device_ip_block_add(adev,
_ih_ip_block);
+ else
+ amdgpu_device_ip_block_add(adev,
_ih_ip_block);
if (likely(adev->firmware.load_type ==
AMDGPU_FW_LOAD_PSP)) {
if (adev->asic_type == CHIP_VEGA20)
amdgpu_device_ip_block_add(adev,
_v11_0_ip_block);
@@ -787,9 +794,9 @@ int soc15_set_ip_blocks(struct amdgpu_device *adev)
if (amdgpu_sriov_vf(adev)) {
if (likely(adev->firmware.load_type ==
AMDGPU_FW_LOAD_PSP))
amdgpu_device_ip_block_add(adev,
_v11_0_ip_block);
- amdgpu_device_ip_block_add(adev, _ih_ip_block);
+ amdgpu_device_ip_block_add(adev, _ih_ip_block);
} else {
- amdgpu_device_ip_block_add(adev, _ih_ip_block);
+ amdgpu_device_ip_block_add(adev, _ih_ip_block);
if (likely(adev->firmware.load_type ==
AMDGPU_FW_LOAD_PSP))
amdgpu_device_ip_block_add(adev,
_v11_0_ip_block);
}
--
2.17.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfxdata=04%7C01%7Calexander.deucher%40amd.com%7C1f54f989cd9641c49c9708d87d4a000e%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637397104709391689%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=fe%2FU57bvUywZ57162F0sTzo%2FDaYGtX62J0MJf36Nxfo%3Dreserved=0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu: fix NULL pointer crash on navi10 headless SKU
[AMD Public Use]
Maybe it would be easier to check if the DCE IP exists? E.g.,
if (!amdgpu_device_ip_get_ip_block(adev, AMD_IP_BLOCK_TYPE_DCE) ||
(!amdgpu_device_has_dc_support(adev))
...
Also do we even need to skip DCN init for these cards, or will the display code
handle it automatically since there will be no displays in the atombios object
table. We didn't do anything special for display with the polaris blockchain
cards.
Alex
From: Zhang, Hawking
Sent: Friday, October 30, 2020 9:00 AM
To: Yin, Tianci (Rico) ; amd-gfx@lists.freedesktop.org
Cc: Tuikov, Luben ; Deucher, Alexander
; Chen, Guchun ; Cui, Flora
; Xu, Feifei ; Long, Gang
Subject: RE: [PATCH] drm/amdgpu: fix NULL pointer crash on navi10 headless SKU
[AMD Public Use]
[AMD Public Use]
I see, thanks for the clarifying. The patch is
Reviewed-by: Hawking Zhang
I was thinking to have a new flag like AMD_IS_HEADLESS in amd_chip_flag, but
after think it a bit more, that’s just complicated the case, I agree with your
current approach.
Regards,
Hawking
From: Yin, Tianci (Rico)
Sent: Friday, October 30, 2020 20:05
To: Zhang, Hawking ; amd-gfx@lists.freedesktop.org
Cc: Tuikov, Luben ; Deucher, Alexander
; Chen, Guchun ; Cui, Flora
; Xu, Feifei ; Long, Gang
Subject: Re: [PATCH] drm/amdgpu: fix NULL pointer crash on navi10 headless SKU
[AMD Public Use]
Hi Hawking,
amdgpu_device_asic_has_dc_support() is referrenced by amdgpu_pci_probe(),
at that point, adev has not been allocated yet.
My change can make it to right code path.
int amdgpu_device_resume(struct drm_device *dev, bool fbcon)
{
...
if (!amdgpu_device_has_dc_support(adev))
drm_helper_hpd_irq_event(dev); //right path for headless SKU
else
drm_kms_helper_hotplug_event(dev); //wrong path for headless SKU
...
}
Thanks!
Rico
From: Zhang, Hawking mailto:hawking.zh...@amd.com>>
Sent: Friday, October 30, 2020 19:48
To: Yin, Tianci (Rico) mailto:tianci@amd.com>>;
amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>
mailto:amd-gfx@lists.freedesktop.org>>
Cc: Tuikov, Luben mailto:luben.tui...@amd.com>>; Deucher,
Alexander mailto:alexander.deuc...@amd.com>>; Chen,
Guchun mailto:guchun.c...@amd.com>>; Cui, Flora
mailto:flora@amd.com>>; Xu, Feifei
mailto:feifei...@amd.com>>; Long, Gang
mailto:gang.l...@amd.com>>; Yin, Tianci (Rico)
mailto:tianci@amd.com>>
Subject: RE: [PATCH] drm/amdgpu: fix NULL pointer crash on navi10 headless SKU
[AMD Public Use]
I'm not sure I get your point on changing amdgpu_device_has_dc_support()
interface by adding new parameter. but it seems to me change input parameter
from pdev to adev for nv_is_headless_sku is more straightforward.
Regards,
Hawking
-Original Message-
From: Tianci Yin mailto:tianci@amd.com>>
Sent: Friday, October 30, 2020 19:32
To: amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>
Cc: Tuikov, Luben mailto:luben.tui...@amd.com>>; Deucher,
Alexander mailto:alexander.deuc...@amd.com>>; Zhang,
Hawking mailto:hawking.zh...@amd.com>>; Chen, Guchun
mailto:guchun.c...@amd.com>>; Cui, Flora
mailto:flora@amd.com>>; Xu, Feifei
mailto:feifei...@amd.com>>; Long, Gang
mailto:gang.l...@amd.com>>; Yin, Tianci (Rico)
mailto:tianci@amd.com>>
Subject: [PATCH] drm/amdgpu: fix NULL pointer crash on navi10 headless SKU
From: "Tianci.Yin" mailto:tianci@amd.com>>
The crash caused by the NULL pointer of
adev->ddev.mode_config.funcs in drm_kms_helper_hotplug_event(),
but this function should not be called on headless SKU.
Fix the mismatch between the return value of
amdgpu_device_has_dc_support() and the real DCN supporting state to avoid
calling to drm_kms_helper_hotplug_event() in amdgpu_device_resume().
Change-Id: I3a3d387e6ab5b774abb3911ea1bf6de60797759d
Signed-off-by: Tianci.Yin mailto:tianci@amd.com>>
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 10 --
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +-
drivers/gpu/drm/amd/amdgpu/nv.c | 2 +-
drivers/gpu/drm/amd/amdgpu/nv.h | 1 +
6 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index ba65d4f2ab67..f0183271456f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1090,7 +1090,7 @@ void amdgpu_device_indirect_wreg64(struct amdgpu_device
*adev,
u32 pcie_index, u32 pcie_data,
u32 reg_addr, u64 reg_data);
-bool amdgpu_device_asic_has_dc_support(enum amd_asic_type asic_type);
+bool amdgpu
Re: [PATCH] drm/amdgpu: cleanup gmc_v9_0_process_interrupt
[AMD Official Use Only - Internal Distribution Only]
Reviewed-by: Alex Deucher
From: amd-gfx on behalf of Christian
König
Sent: Wednesday, October 28, 2020 9:49 AM
To: amd-gfx@lists.freedesktop.org
Subject: [PATCH] drm/amdgpu: cleanup gmc_v9_0_process_interrupt
First of all don't snprintf into a char buffer allocated on the stack with
a constant hubname.
Then cleanup to exit the function early in case of a ratelimit or SRIOV.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 183 +-
1 file changed, 91 insertions(+), 92 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
index a9929d1b6b3d..0c3421d587e8 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
@@ -510,15 +510,16 @@ static int gmc_v9_0_vm_fault_interrupt_state(struct
amdgpu_device *adev,
}
static int gmc_v9_0_process_interrupt(struct amdgpu_device *adev,
- struct amdgpu_irq_src *source,
- struct amdgpu_iv_entry *entry)
+ struct amdgpu_irq_src *source,
+ struct amdgpu_iv_entry *entry)
{
- struct amdgpu_vmhub *hub;
bool retry_fault = !!(entry->src_data[1] & 0x80);
uint32_t status = 0, cid = 0, rw = 0;
- u64 addr;
- char hub_name[10];
+ struct amdgpu_task_info task_info;
+ struct amdgpu_vmhub *hub;
const char *mmhub_cid;
+ const char *hub_name;
+ u64 addr;
addr = (u64)entry->src_data[0] << 12;
addr |= ((u64)entry->src_data[1] & 0xf) << 44;
@@ -527,105 +528,103 @@ static int gmc_v9_0_process_interrupt(struct
amdgpu_device *adev,
entry->timestamp))
return 1; /* This also prevents sending it to KFD */
+ /* If it's the first fault for this address, process it normally */
+ if (retry_fault && !in_interrupt() &&
+ amdgpu_vm_handle_fault(adev, entry->pasid, addr))
+ return 1; /* This also prevents sending it to KFD */
+
+ if (!printk_ratelimit())
+ return 0;
+
if (entry->client_id == SOC15_IH_CLIENTID_VMC) {
- snprintf(hub_name, sizeof(hub_name), "mmhub0");
+ hub_name = "mmhub0";
hub = >vmhub[AMDGPU_MMHUB_0];
} else if (entry->client_id == SOC15_IH_CLIENTID_VMC1) {
- snprintf(hub_name, sizeof(hub_name), "mmhub1");
+ hub_name = "mmhub1";
hub = >vmhub[AMDGPU_MMHUB_1];
} else {
- snprintf(hub_name, sizeof(hub_name), "gfxhub0");
+ hub_name = "gfxhub0";
hub = >vmhub[AMDGPU_GFXHUB_0];
}
- /* If it's the first fault for this address, process it normally */
- if (retry_fault && !in_interrupt() &&
- amdgpu_vm_handle_fault(adev, entry->pasid, addr))
- return 1; /* This also prevents sending it to KFD */
+ memset(_info, 0, sizeof(struct amdgpu_task_info));
+ amdgpu_vm_get_task_info(adev, entry->pasid, _info);
- if (!amdgpu_sriov_vf(adev)) {
- /*
-* Issue a dummy read to wait for the status register to
-* be updated to avoid reading an incorrect value due to
-* the new fast GRBM interface.
-*/
- if (entry->vmid_src == AMDGPU_GFXHUB_0)
- RREG32(hub->vm_l2_pro_fault_status);
-
- status = RREG32(hub->vm_l2_pro_fault_status);
- cid = REG_GET_FIELD(status,
- VM_L2_PROTECTION_FAULT_STATUS, CID);
- rw = REG_GET_FIELD(status,
- VM_L2_PROTECTION_FAULT_STATUS, RW);
- WREG32_P(hub->vm_l2_pro_fault_cntl, 1, ~1);
- }
+ dev_err(adev->dev,
+ "[%s] %s page fault (src_id:%u ring:%u vmid:%u "
+ "pasid:%u, for process %s pid %d thread %s pid %d)\n",
+ hub_name, retry_fault ? "retry" : "no-retry",
+ entry->src_id, entry->ring_id, entry->vmid,
+ entry->pasid, task_info.process_name, task_info.tgid,
+ task_info.task_name, task_info.pid);
+ dev_err(adev->dev, " in page starting at address 0x%016llx from client
%d\n",
+ addr, entry->client_id);
- if (printk_ratelimit()) {
- struct amdgpu_task_info task_info;
-
- memset(_info, 0, sizeof(struct amdgpu_task_info));
- amdgpu_vm_get_task_info(adev, entry->pasid, _info);
-
- dev_err(adev->dev,
- "[%s] %s page fault (src_id:%u ring:%u vmid:%u "
- "pasid:%u, for process %s pid %d thread %s pid %d)\n",
- hub_name,
Re: [PATCH 5/5] drm/amd/pm: do not use ixFEATURE_STATUS for checking smc running
[AMD Public Use]
Series is:
Reviewed-by: Alex Deucher
From: Quan, Evan
Sent: Wednesday, October 28, 2020 4:30 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; sandy.8...@gmail.com
; Quan, Evan
Subject: [PATCH 5/5] drm/amd/pm: do not use ixFEATURE_STATUS for checking smc
running
This reverts commit f87812284172a9809820d10143b573d833cd3f75 "drm/amdgpu:
Fix bug where DPM is not enabled after hibernate and resume".
It was intended to fix Hawaii S4(hibernation) issue but break S3. As
ixFEATURE_STATUS is filled with garbage data on resume which can be
only cleared by reloading smc firmware(but that will involve many
changes). So, we will revert this S4 fix and seek a new way.
Change-Id: If9eed2f5a9c1168fb20be92057b583d854ad779e
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/pm/powerplay/smumgr/ci_smumgr.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/powerplay/smumgr/ci_smumgr.c
b/drivers/gpu/drm/amd/pm/powerplay/smumgr/ci_smumgr.c
index 09128122b493..329bf4d44bbc 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/smumgr/ci_smumgr.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/smumgr/ci_smumgr.c
@@ -2726,10 +2726,7 @@ static int ci_initialize_mc_reg_table(struct pp_hwmgr
*hwmgr)
static bool ci_is_dpm_running(struct pp_hwmgr *hwmgr)
{
- return (1 == PHM_READ_INDIRECT_FIELD(hwmgr->device,
-CGS_IND_REG__SMC, FEATURE_STATUS,
-VOLTAGE_CONTROLLER_ON))
- ? true : false;
+ return ci_is_smc_ram_running(hwmgr);
}
static int ci_smu_init(struct pp_hwmgr *hwmgr)
--
2.29.0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 2/2] drm/amd/pm: fix compile warnings about variable used uninitialized
[AMD Official Use Only - Internal Distribution Only]
Series is:
Reviewed-by: Alex Deucher
From: Quan, Evan
Sent: Tuesday, October 27, 2020 10:45 PM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Quan, Evan
; kernel test robot
Subject: [PATCH 2/2] drm/amd/pm: fix compile warnings about variable used
uninitialized
Fix the compile warnings below:
>> drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu7_hwmgr.c:1743:13:
>> warning: variable 'min' is used uninitialized whenever 'if' condition is
>> false [-Wsometimes-uninitialized]
>> drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu7_hwmgr.c:1743:13:
>> warning: variable 'max' is used uninitialized whenever 'if' condition is
>> false [-Wsometimes-uninitialized]
Change-Id: Id2dece80162cd10f004abbf3b62cba0c84e988f2
Signed-off-by: Evan Quan
Reported-by: kernel test robot
---
drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c
b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c
index 49db61a89505..5937150e6b37 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c
@@ -1856,7 +1856,7 @@ static int smu7_calculate_ro_range(struct pp_hwmgr *hwmgr)
{
struct smu7_hwmgr *data = (struct smu7_hwmgr *)(hwmgr->backend);
struct amdgpu_device *adev = hwmgr->adev;
- uint32_t asicrev1, evv_revision, max, min;
+ uint32_t asicrev1, evv_revision, max = 0, min = 0;
atomctrl_read_efuse(hwmgr, STRAP_EVV_REVISION_LSB,
STRAP_EVV_REVISION_MSB,
_revision);
@@ -1893,8 +1893,7 @@ static int smu7_calculate_ro_range(struct pp_hwmgr *hwmgr)
max = 2500;
}
}
- } else if ((hwmgr->chip_id == CHIP_POLARIS11) ||
- (hwmgr->chip_id == CHIP_POLARIS12)) {
+ } else {
min = 1100;
max = 2100;
}
--
2.29.0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu: add vangogh apu flag
[AMD Public Use]
Acked-by: Alex Deucher
From: amd-gfx on behalf of Huang Rui
Sent: Monday, October 26, 2020 8:51 AM
To: amd-gfx@lists.freedesktop.org
Cc: Huang, Ray
Subject: [PATCH] drm/amdgpu: add vangogh apu flag
This patch is to add vangogh apu flag to support more kickers that
belongs vangogh series.
Signed-off-by: Huang Rui
---
drivers/gpu/drm/amd/amdgpu/nv.c | 4 +++-
drivers/gpu/drm/amd/include/amd_shared.h | 1 +
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/nv.c b/drivers/gpu/drm/amd/amdgpu/nv.c
index 30ec826c8760..b7fc9ebdf1c1 100644
--- a/drivers/gpu/drm/amd/amdgpu/nv.c
+++ b/drivers/gpu/drm/amd/amdgpu/nv.c
@@ -941,6 +941,7 @@ static int nv_common_early_init(void *handle)
break;
case CHIP_VANGOGH:
+ adev->apu_flags |= AMD_APU_IS_VANGOGH;
adev->cg_flags = AMD_CG_SUPPORT_GFX_CGCG |
AMD_CG_SUPPORT_GFX_CGLS |
AMD_CG_SUPPORT_GFX_3D_CGCG |
@@ -951,7 +952,8 @@ static int nv_common_early_init(void *handle)
AMD_PG_SUPPORT_VCN |
AMD_PG_SUPPORT_VCN_DPG |
AMD_PG_SUPPORT_JPEG;
- adev->external_rev_id = adev->rev_id + 0x01;
+ if (adev->apu_flags & AMD_APU_IS_VANGOGH)
+ adev->external_rev_id = adev->rev_id + 0x01;
break;
case CHIP_DIMGREY_CAVEFISH:
adev->cg_flags = AMD_CG_SUPPORT_GFX_MGCG |
diff --git a/drivers/gpu/drm/amd/include/amd_shared.h
b/drivers/gpu/drm/amd/include/amd_shared.h
index 06c1aabf10ce..412602d84f71 100644
--- a/drivers/gpu/drm/amd/include/amd_shared.h
+++ b/drivers/gpu/drm/amd/include/amd_shared.h
@@ -46,6 +46,7 @@ enum amd_apu_flags {
AMD_APU_IS_PICASSO = 0x0004UL,
AMD_APU_IS_RENOIR = 0x0008UL,
AMD_APU_IS_GREEN_SARDINE = 0x0010UL,
+ AMD_APU_IS_VANGOGH = 0x0020UL,
};
/**
--
2.25.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfxdata=04%7C01%7Calexander.deucher%40amd.com%7C997d0fa293f94eec44b008d879adfbcd%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637393135475905040%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=4zu%2FHsq0nTrx7NL4Dkqupaaet%2Fwzc40zzlXcYQXXbZU%3Dreserved=0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
RE: amdgpu crashes on OOM
[AMD Public Use] > -Original Message- > From: Michel Dänzer > Sent: Monday, October 26, 2020 7:04 AM > To: Alex Xu (Hello71) ; Kazlauskas, Nicholas > ; Deucher, Alexander > ; Wentland, Harry > ; Li, Sun peng (Leo) ; > amd-gfx@lists.freedesktop.org > Cc: linux-ker...@vger.kernel.org > Subject: Re: amdgpu crashes on OOM > > On 2020-10-26 5:29 a.m., Alex Xu (Hello71) wrote: > > Hi, > > > > I frequently encounter OOM on my system, mostly due to my own fault. > > Recently, I noticed that not only does a swap storm happen and OOM > > killer gets invoked, but the graphics output freezes permanently. > > Checking the kernel messages, I see: > > > > kworker/u24:4: page allocation failure: order:5, > mode:0x40dc0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO), > nodemask=(null) > > CPU: 6 PID: 279469 Comm: kworker/u24:4 Tainted: GW > > 5.9.0-14732- > g20b1adb60cf6 #2 > > Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./B450 > > Pro4, BIOS P4.20 06/18/2020 > > Workqueue: events_unbound commit_work > > Call Trace: > > ? dump_stack+0x57/0x6a > > ? warn_alloc.cold+0x69/0xcd > > ? __alloc_pages_direct_compact+0xfb/0x116 > > ? __alloc_pages_slowpath.constprop.0+0x9c2/0xc14 > > ? __alloc_pages_nodemask+0x143/0x167 > > ? kmalloc_order+0x24/0x64 > > ? dc_create_state+0x1a/0x4d > > ? amdgpu_dm_atomic_commit_tail+0x1b19/0x227d > > Looks like dc_create_state should use kvzalloc instead of kzalloc > (dc_state_free already uses kvfree). > > order:5 means it's trying to allocate 32 physically contiguous pages, which > can > be hard to fulfill even with lower memory pressure. > It was using kvzalloc, but was accidently dropped when that code was refactored. I just sent a patch to fix it. Alex > > -- > Earthling Michel Dänzer | > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fredh > at.com%2Fdata=04%7C01%7Calexander.deucher%40amd.com%7Cc60 > 56551dd4d423bdc0508d8799ed189%7C3dd8961fe4884e608e11a82d994e183d > %7C0%7C0%7C637393070333648663%7CUnknown%7CTWFpbGZsb3d8eyJWIj > oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1 > 000sdata=a7Lpu04KnpsFQpCO7y5WOLJSMPpA%2Be1s%2FufgYTDHs2k > %3Dreserved=0 > Libre software enthusiast | Mesa and X developer ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu: drop mem_global_referenced
[AMD Public Use]
Reviewed-by: Alex Deucher
From: amd-gfx on behalf of Christian
König
Sent: Monday, October 26, 2020 5:29 AM
To: amd-gfx@lists.freedesktop.org
Subject: [PATCH] drm/amdgpu: drop mem_global_referenced
Not used any more.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
index 68c5e3662b87..d808b2a58b28 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
@@ -58,7 +58,6 @@ struct amdgpu_gtt_mgr {
struct amdgpu_mman {
struct ttm_bo_devicebdev;
- boolmem_global_referenced;
boolinitialized;
void __iomem*aper_base_kaddr;
--
2.17.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfxdata=04%7C01%7Calexander.deucher%40amd.com%7Ccd8ff5e90c384fadb84308d879919c44%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637393013597084067%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=WaPRmdfK6tnkLkM2PqpEeTv86hilcxdSklXb%2FeloGso%3Dreserved=0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu: enable VCN PG and CG for vangogh
[AMD Public Use] Reviewed-by: Alex Deucher From: amd-gfx on behalf of Zhang, Boyuan Sent: Friday, October 16, 2020 7:28 PM To: amd-gfx@lists.freedesktop.org Subject: [PATCH] drm/amdgpu: enable VCN PG and CG for vangogh [AMD Official Use Only - Internal Distribution Only] [AMD Official Use Only - Internal Distribution Only] Enable VCN 3.0 PG and CG for Vangogh by setting up flags. Signed-off-by: Boyuan Zhang --- drivers/gpu/drm/amd/amdgpu/nv.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/nv.c b/drivers/gpu/drm/amd/amdgpu/nv.c index 4b1a4acb60d9..ce787489aaeb 100644 --- a/drivers/gpu/drm/amd/amdgpu/nv.c +++ b/drivers/gpu/drm/amd/amdgpu/nv.c @@ -938,8 +938,13 @@ static int nv_common_early_init(void *handle) adev->cg_flags = AMD_CG_SUPPORT_GFX_CGCG | AMD_CG_SUPPORT_GFX_CGLS | AMD_CG_SUPPORT_GFX_3D_CGCG | - AMD_CG_SUPPORT_GFX_3D_CGLS; - adev->pg_flags = AMD_PG_SUPPORT_GFX_PG; + AMD_CG_SUPPORT_GFX_3D_CGLS | + AMD_CG_SUPPORT_VCN_MGCG | + AMD_CG_SUPPORT_JPEG_MGCG; + adev->pg_flags = AMD_PG_SUPPORT_GFX_PG | + AMD_PG_SUPPORT_VCN | + AMD_PG_SUPPORT_VCN_DPG | + AMD_PG_SUPPORT_JPEG; adev->external_rev_id = adev->rev_id + 0x01; break; -- 2.25.1 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amd/psp: Fix sysfs: cannot create duplicate filename
[AMD Public Use] Reviewed-by: Alex Deucher Want to add a Fixes: tag? From: amd-gfx on behalf of Andrey Grodzovsky Sent: Friday, October 16, 2020 10:52 AM To: amd-gfx@lists.freedesktop.org Cc: Grodzovsky, Andrey ; Zhang, Jack (Jian) Subject: [PATCH] drm/amd/psp: Fix sysfs: cannot create duplicate filename psp sysfs not cleaned up on driver unload for sienna_cichlid Signed-off-by: Andrey Grodzovsky --- drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c index 803b3ab..675b14a 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c @@ -210,7 +210,8 @@ static int psp_sw_fini(void *handle) adev->psp.ta_fw = NULL; } - if (adev->asic_type == CHIP_NAVI10) + if (adev->asic_type == CHIP_NAVI10 || + adev->asic_type == CHIP_SIENNA_CICHLID) psp_sysfs_fini(adev); return 0; -- 2.7.4 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfxdata=04%7C01%7Calexander.deucher%40amd.com%7C4b9827047c1f4f1a535908d871e3193a%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637384567500193749%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=klYQ7ZzcmrPbXDeEARNHMTjJMUyZWPSn7N3KTQZ2%2FMc%3Dreserved=0 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 2/2] drm/amd/display: Fix DCN302 makefile
[AMD Public Use] Series is: Reviewed-by: Alex Deucher From: Bhawanpreet Lakha Sent: Thursday, October 15, 2020 2:20 PM To: Kazlauskas, Nicholas ; Deucher, Alexander Cc: rodrigo.siqofue...@amd.com ; amd-gfx@lists.freedesktop.org ; Lakha, Bhawanpreet Subject: [PATCH 2/2] drm/amd/display: Fix DCN302 makefile Some setups will fail to build. So copy dcn301 makefile setup which is known to work Signed-off-by: Bhawanpreet Lakha --- .../gpu/drm/amd/display/dc/dcn302/Makefile| 29 +++ 1 file changed, 29 insertions(+) diff --git a/drivers/gpu/drm/amd/display/dc/dcn302/Makefile b/drivers/gpu/drm/amd/display/dc/dcn302/Makefile index 3ea9bff27912..36e44e1b07fa 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn302/Makefile +++ b/drivers/gpu/drm/amd/display/dc/dcn302/Makefile @@ -12,6 +12,35 @@ DCN3_02 = dcn302_init.o dcn302_hwseq.o dcn302_resource.o +ifdef CONFIG_X86 +CFLAGS_$(AMDDALPATH)/dc/dcn302/dcn302_resource.o := -mhard-float -msse +endif + +ifdef CONFIG_PPC64 +CFLAGS_$(AMDDALPATH)/dc/dcn302/dcn302_resource.o := -mhard-float -maltivec +endif + +ifdef CONFIG_ARM64 +CFLAGS_REMOVE_$(AMDDALPATH)/dc/dcn302/dcn302_resource.o := -mgeneral-regs-only +endif + +ifdef CONFIG_CC_IS_GCC +ifeq ($(call cc-ifversion, -lt, 0701, y), y) +IS_OLD_GCC = 1 +endif +endif + +ifdef CONFIG_X86 +ifdef IS_OLD_GCC +# Stack alignment mismatch, proceed with caution. +# GCC < 7.1 cannot compile code using `double` and -mpreferred-stack-boundary=3 +# (8B stack alignment). +CFLAGS_$(AMDDALPATH)/dc/dcn302/dcn302_resource.o += -mpreferred-stack-boundary=4 +else +CFLAGS_$(AMDDALPATH)/dc/dcn302/dcn302_resource.o += -msse2 +endif +endif + AMD_DAL_DCN3_02 = $(addprefix $(AMDDALPATH)/dc/dcn302/,$(DCN3_02)) AMD_DISPLAY_FILES += $(AMD_DAL_DCN3_02) -- 2.25.1 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 2/2] drm/amdgpu/display: enable display ip block for vangogh
[AMD Official Use Only - Internal Distribution Only] Series is: Reviewed-by: Alex Deucher From: Huang, Ray Sent: Thursday, October 15, 2020 4:28 AM To: amd-gfx@lists.freedesktop.org Cc: Wentland, Harry ; Li, Roman ; Deucher, Alexander ; Huang, Ray Subject: [PATCH 2/2] drm/amdgpu/display: enable display ip block for vangogh This patch is to enable display IP block for vangogh platforms. Signed-off-by: Huang Rui --- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 1 + drivers/gpu/drm/amd/amdgpu/nv.c| 4 2 files changed, 5 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c index a2f0ce854160..15ffb47bd1f0 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c @@ -3014,6 +3014,7 @@ bool amdgpu_device_asic_has_dc_support(enum amd_asic_type asic_type) case CHIP_SIENNA_CICHLID: case CHIP_NAVY_FLOUNDER: case CHIP_DIMGREY_CAVEFISH: + case CHIP_VANGOGH: #endif return amdgpu_dc != 0; #endif diff --git a/drivers/gpu/drm/amd/amdgpu/nv.c b/drivers/gpu/drm/amd/amdgpu/nv.c index 47bd79c9e6ea..217533e2f181 100644 --- a/drivers/gpu/drm/amd/amdgpu/nv.c +++ b/drivers/gpu/drm/amd/amdgpu/nv.c @@ -621,6 +621,10 @@ int nv_set_ip_blocks(struct amdgpu_device *adev) amdgpu_device_ip_block_add(adev, _v11_0_ip_block); if (adev->enable_virtual_display || amdgpu_sriov_vf(adev)) amdgpu_device_ip_block_add(adev, _virtual_ip_block); +#if defined(CONFIG_DRM_AMD_DC) + else if (amdgpu_device_has_dc_support(adev)) + amdgpu_device_ip_block_add(adev, _ip_block); +#endif amdgpu_device_ip_block_add(adev, _v10_0_ip_block); amdgpu_device_ip_block_add(adev, _v5_2_ip_block); amdgpu_device_ip_block_add(adev, _v3_0_ip_block); -- 2.25.1 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu: update golden setting for sienna_cichlid
[AMD Public Use] Acked-by: Alex Deucher From: amd-gfx on behalf of Likun Gao Sent: Wednesday, October 14, 2020 10:57 PM To: amd-gfx@lists.freedesktop.org Cc: Gao, Likun ; Zhang, Hawking Subject: [PATCH] drm/amdgpu: update golden setting for sienna_cichlid From: Likun Gao Update golden setting for sienna_cichlid. Signed-off-by: Likun Gao Change-Id: I9a1ad84c22748fc100a3327487c6287e237df490 --- drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c index c4e9db3be39a..69e995155594 100644 --- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c @@ -3138,6 +3138,7 @@ static const struct soc15_reg_golden golden_settings_gc_10_3[] = SOC15_REG_GOLDEN_VALUE(GC, 0, mmGL2C_ADDR_MATCH_MASK, 0x, 0xffcf), SOC15_REG_GOLDEN_VALUE(GC, 0, mmGL2C_CM_CTRL1, 0xff8fff0f, 0x580f1008), SOC15_REG_GOLDEN_VALUE(GC, 0, mmGL2C_CTRL3, 0xf7ff, 0x10f80988), + SOC15_REG_GOLDEN_VALUE(GC, 0, mmLDS_CONFIG, 0x0020, 0x0020), SOC15_REG_GOLDEN_VALUE(GC, 0, mmPA_CL_ENHANCE, 0xf17f, 0x0127), SOC15_REG_GOLDEN_VALUE(GC, 0, mmPA_SC_BINNER_TIMEOUT_COUNTER, 0x, 0x0800), SOC15_REG_GOLDEN_VALUE(GC, 0, mmPA_SC_ENHANCE_2, 0xffbf, 0x0820), -- 2.25.1 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfxdata=02%7C01%7Calexander.deucher%40amd.com%7C1c27e62b5c5343737d4808d870b62790%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637383274974363126sdata=9HWTZz2G%2B2vTyLoQp9DuFltve2bSs2HFYai072wZB8A%3Dreserved=0 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] Revert "drm/amdgpu: disable gfxoff temporarily for navy_flounder"
[AMD Public Use] Acked-by: Alex Deucher From: amd-gfx on behalf of Jiansong Chen Sent: Wednesday, October 14, 2020 10:46 PM To: amd-gfx@lists.freedesktop.org Cc: Chen, Jiansong (Simon) ; Zhou1, Tao ; Zhang, Hawking Subject: [PATCH] Revert "drm/amdgpu: disable gfxoff temporarily for navy_flounder" This reverts commit 7e59138e97574e8dbecd1f259581277fff555d00. TDR issue has been resovled by pmfw update. Change-Id: Ia04709c4ba13835abfdec56558738bf6fbfac20d --- drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c index 8fc69c208adb..be13495b97f1 100644 --- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c @@ -3723,7 +3723,6 @@ static void gfx_v10_0_check_gfxoff_flag(struct amdgpu_device *adev) if (!gfx_v10_0_navi10_gfxoff_should_enable(adev)) adev->pm.pp_feature &= ~PP_GFXOFF_MASK; break; - case CHIP_NAVY_FLOUNDER: case CHIP_VANGOGH: adev->pm.pp_feature &= ~PP_GFXOFF_MASK; break; -- 2.25.1 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfxdata=02%7C01%7Calexander.deucher%40amd.com%7C567c2489998d4d6b96f208d870b49e3a%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637383268948419311sdata=g6fKcr%2BozqHqtFzIdvv5R9ZzuOWj5sRrTqZ%2Bbhn9ruM%3Dreserved=0 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdkfd: Use kvfree in destroy_crat_image
[AMD Official Use Only - Internal Distribution Only]
Reviewed-by: Alex Deucher
From: amd-gfx on behalf of Kent Russell
Sent: Wednesday, October 14, 2020 7:51 AM
To: amd-gfx@lists.freedesktop.org
Cc: Russell, Kent
Subject: [PATCH] drm/amdkfd: Use kvfree in destroy_crat_image
Now that we use kvmalloc for the crat_image, we need to use kvfree when
we destroy this.
Fixes: a522a06f8044 ("drm/amdkfd: Use kvmalloc instead of kmalloc for VCRAT")
Reported-by: Morris Zhang
Signed-off-by: Kent Russell
---
drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
index 7a071b4f76a7..cdd5032d5c0e 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
@@ -1432,5 +1432,5 @@ int kfd_create_crat_image_virtual(void **crat_image,
size_t *size,
*/
void kfd_destroy_crat_image(void *crat_image)
{
- kfree(crat_image);
+ kvfree(crat_image);
}
--
2.17.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfxdata=02%7C01%7Calexander.deucher%40amd.com%7Cf0637add750e4736c8ec08d87037885d%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637382731137392526sdata=oIKYRCK86ld1JxjEsd1EyGsSlskNVyQogIO3spENv0M%3Dreserved=0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amd/pm: increase mclk switch threshold to 200 us
[AMD Official Use Only - Internal Distribution Only] Acked-by: Alex Deucher From: Quan, Evan Sent: Tuesday, October 13, 2020 2:45 AM To: amd-gfx@lists.freedesktop.org Cc: Deucher, Alexander ; Quan, Evan Subject: [PATCH] drm/amd/pm: increase mclk switch threshold to 200 us To avoid underflow seen on Polaris10 with some 3440x1440 144Hz displays. As the threshold of 190 us cuts too close to minVBlankTime of 192 us. Change-Id: Ieca0dc900f0b5764dc661e397e41e8c277ff13de Signed-off-by: Evan Quan --- drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c index 3bf8be4d107b..1e8919b0acdb 100644 --- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c +++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c @@ -2883,7 +2883,7 @@ static int smu7_vblank_too_short(struct pp_hwmgr *hwmgr, if (hwmgr->is_kicker) switch_limit_us = data->is_memory_gddr5 ? 450 : 150; else - switch_limit_us = data->is_memory_gddr5 ? 190 : 150; + switch_limit_us = data->is_memory_gddr5 ? 200 : 150; break; case CHIP_VEGAM: switch_limit_us = 30; -- 2.28.0 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
RE: [PATCH] PCI/ACPI: Whitelist hotplug ports for D3 if power managed by ACPI
[AMD Public Use] > -Original Message- > From: Rafael J. Wysocki > Sent: Friday, October 2, 2020 10:25 AM > To: Deucher, Alexander > Cc: Rafael J. Wysocki ; Lukas Wunner > ; Aaron Zakhrov ; Michal > Rostecki ; Linux PCI ; > Rafael J. Wysocki ; amd-gfx list g...@lists.freedesktop.org>; ACPI Devel Maling List a...@vger.kernel.org>; Shai Coleman ; Bjorn > Helgaas ; Arthur Borsboom > ; matoro ; Mika > Westerberg ; Len Brown > > Subject: Re: [PATCH] PCI/ACPI: Whitelist hotplug ports for D3 if power > managed by ACPI > > On Fri, Oct 2, 2020 at 4:20 PM Deucher, Alexander > wrote: > > > > [AMD Public Use] > > > > > -Original Message- > > > From: amd-gfx On Behalf Of > > > Rafael J. Wysocki > > > Sent: Friday, October 2, 2020 10:17 AM > > > To: Lukas Wunner > > > Cc: Aaron Zakhrov ; Michal Rostecki > > > ; Linux PCI ; Rafael J. > > > Wysocki ; amd-gfx list > > g...@lists.freedesktop.org>; ACPI Devel Maling List > > a...@vger.kernel.org>; Shai Coleman ; Bjorn > > > Helgaas ; Arthur Borsboom > > > ; matoro ; Deucher, > > > Alexander ; Mika Westerberg > > > ; Len Brown > > > Subject: Re: [PATCH] PCI/ACPI: Whitelist hotplug ports for D3 if > > > power managed by ACPI > > > > > > On Fri, Oct 2, 2020 at 7:17 AM Lukas Wunner wrote: > > > > > > > > Recent laptops with dual AMD GPUs fail to suspend the discrete > > > > GPU, thus causing lockups on system sleep and high power > > > > consumption at > > > runtime. > > > > The discrete GPU would normally be suspended to D3cold by turning > > > > off ACPI _PR3 Power Resources of the Root Port above the GPU. > > > > > > > > However on affected systems, the Root Port is hotplug-capable and > > > > pci_bridge_d3_possible() only allows hotplug ports to go to D3 if > > > > they belong to a Thunderbolt device or if the Root Port possesses > > > > a "HotPlugSupportInD3" ACPI property. Neither is the case on > > > > affected laptops. The reason for whitelisting only specific, > > > > known to work hotplug ports for D3 is that there have been reports > > > > of SkyLake Xeon-SP systems raising Hardware Error NMIs upon > > > > suspending their > > > hotplug ports: > > > > > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flo > > > re > > > > .kernel.org%2Flinux-pci%2F20170503180426.GA4058%40otc-nc- > > > 03%2Fdat > > > > > > > > a=02%7C01%7Calexander.deucher%40amd.com%7C99ec20b6d4dc410baf800 > > > 8d866dd > > > > > > > > e688%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C6373724505855 > > > 84491 > > > > > > > > mp;sdata=EPFyxPA0MDBuAkvH7bbp2wHYnpos8p%2BoZmzlUvvdAek%3D > > > mp;reserved > > > > =0 > > > > > > > > But if a hotplug port is power manageable by ACPI (as can be > > > > detected through presence of Power Resources and corresponding > > > > _PS0 and _PS3 > > > > methods) then it ought to be safe to suspend it to D3. To this > > > > end, amend acpi_pci_bridge_d3() to whitelist such ports for D3. > > > > > > > > Link: > > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2F > > > > gitl > > > > ab.freedesktop.org%2Fdrm%2Famd%2F- > > > %2Fissues%2F1222data=02%7C01%7C > > > > > > > > alexander.deucher%40amd.com%7C99ec20b6d4dc410baf8008d866dde688% > > > 7C3dd89 > > > > > > > > 61fe4884e608e11a82d994e183d%7C0%7C0%7C637372450585584491sd > > > ata=cMj > > > > > > > > LDIbjp8RQiWX8pgK2bDUH%2B0u3oquy3TqeT9QjZGE%3Dreserved=0 > > > > Link: > > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2F > > > > gitl > > > > ab.freedesktop.org%2Fdrm%2Famd%2F- > > > %2Fissues%2F1252data=02%7C01%7C > > > > > > > > alexander.deucher%40amd.com%7C99ec20b6d4dc410baf8008d866dde688% > > > 7C3dd89 > > > > > > > > 61fe4884e608e11a82d994e183d%7C0%7C0%7C637372450585584491sd > > > ata=iP9 > > > > > > > > EqNcM15Dj4Ax%2BE6e2HaMWHEX%2B0IO3cMoi0NXWGzM%3Dreser > > > ved=0 > > > > Link: > > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2F > > > > gitl > > > >
RE: [PATCH] PCI/ACPI: Whitelist hotplug ports for D3 if power managed by ACPI
[AMD Public Use]
> -Original Message-
> From: amd-gfx On Behalf Of
> Rafael J. Wysocki
> Sent: Friday, October 2, 2020 10:17 AM
> To: Lukas Wunner
> Cc: Aaron Zakhrov ; Michal Rostecki
> ; Linux PCI ; Rafael J.
> Wysocki ; amd-gfx list g...@lists.freedesktop.org>; ACPI Devel Maling List a...@vger.kernel.org>; Shai Coleman ; Bjorn
> Helgaas ; Arthur Borsboom
> ; matoro ; Deucher,
> Alexander ; Mika Westerberg
> ; Len Brown
> Subject: Re: [PATCH] PCI/ACPI: Whitelist hotplug ports for D3 if power
> managed by ACPI
>
> On Fri, Oct 2, 2020 at 7:17 AM Lukas Wunner wrote:
> >
> > Recent laptops with dual AMD GPUs fail to suspend the discrete GPU,
> > thus causing lockups on system sleep and high power consumption at
> runtime.
> > The discrete GPU would normally be suspended to D3cold by turning off
> > ACPI _PR3 Power Resources of the Root Port above the GPU.
> >
> > However on affected systems, the Root Port is hotplug-capable and
> > pci_bridge_d3_possible() only allows hotplug ports to go to D3 if they
> > belong to a Thunderbolt device or if the Root Port possesses a
> > "HotPlugSupportInD3" ACPI property. Neither is the case on affected
> > laptops. The reason for whitelisting only specific, known to work
> > hotplug ports for D3 is that there have been reports of SkyLake
> > Xeon-SP systems raising Hardware Error NMIs upon suspending their
> hotplug ports:
> >
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore
> > .kernel.org%2Flinux-pci%2F20170503180426.GA4058%40otc-nc-
> 03%2Fdat
> >
> a=02%7C01%7Calexander.deucher%40amd.com%7C99ec20b6d4dc410baf800
> 8d866dd
> >
> e688%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C6373724505855
> 84491
> >
> mp;sdata=EPFyxPA0MDBuAkvH7bbp2wHYnpos8p%2BoZmzlUvvdAek%3D
> mp;reserved
> > =0
> >
> > But if a hotplug port is power manageable by ACPI (as can be detected
> > through presence of Power Resources and corresponding _PS0 and _PS3
> > methods) then it ought to be safe to suspend it to D3. To this end,
> > amend acpi_pci_bridge_d3() to whitelist such ports for D3.
> >
> > Link:
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl
> > ab.freedesktop.org%2Fdrm%2Famd%2F-
> %2Fissues%2F1222data=02%7C01%7C
> >
> alexander.deucher%40amd.com%7C99ec20b6d4dc410baf8008d866dde688%
> 7C3dd89
> >
> 61fe4884e608e11a82d994e183d%7C0%7C0%7C637372450585584491sd
> ata=cMj
> >
> LDIbjp8RQiWX8pgK2bDUH%2B0u3oquy3TqeT9QjZGE%3Dreserved=0
> > Link:
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl
> > ab.freedesktop.org%2Fdrm%2Famd%2F-
> %2Fissues%2F1252data=02%7C01%7C
> >
> alexander.deucher%40amd.com%7C99ec20b6d4dc410baf8008d866dde688%
> 7C3dd89
> >
> 61fe4884e608e11a82d994e183d%7C0%7C0%7C637372450585584491sd
> ata=iP9
> >
> EqNcM15Dj4Ax%2BE6e2HaMWHEX%2B0IO3cMoi0NXWGzM%3Dreser
> ved=0
> > Link:
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl
> > ab.freedesktop.org%2Fdrm%2Famd%2F-
> %2Fissues%2F1304data=02%7C01%7C
> >
> alexander.deucher%40amd.com%7C99ec20b6d4dc410baf8008d866dde688%
> 7C3dd89
> >
> 61fe4884e608e11a82d994e183d%7C0%7C0%7C637372450585584491sd
> ata=VlT
> > UV2UCH4RvKgTXZcpGOpkjZpfijmPgwtvKx6HRT04%3Dreserved=0
> > Reported-and-tested-by: Arthur Borsboom
> > Reported-and-tested-by: matoro
> > Reported-by: Aaron Zakhrov
> > Reported-by: Michal Rostecki
> > Reported-by: Shai Coleman
> > Signed-off-by: Lukas Wunner
> > Cc: sta...@vger.kernel.org
> > Cc: Alex Deucher
> > Cc: Rafael J. Wysocki
> > Cc: Mika Westerberg
> > ---
> > drivers/pci/pci-acpi.c | 10 ++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c index
> > d5869a0..d9aa551 100644
> > --- a/drivers/pci/pci-acpi.c
> > +++ b/drivers/pci/pci-acpi.c
> > @@ -944,6 +944,16 @@ static bool acpi_pci_bridge_d3(struct pci_dev
> *dev)
> > if (!dev->is_hotplug_bridge)
> > return false;
> >
> > + /* Assume D3 support if the bridge is power-manageable by ACPI. */
> > + adev = ACPI_COMPANION(>dev);
> > + if (!adev && !pci_dev_is_added(dev)) {
> > + adev = acpi_pci_find_companion(>dev);
> > + ACPI_COMPANION_SET(>dev, adev);
> > + }
> > +
> > + if (adev && acpi_device_power_manageable(adev))
> > + return true;
> > +
> > /*
> > * Look for a special _DSD property for the root port and if it
> > * is set we know the hierarchy behind it supports D3 just fine.
> > --
>
> I'm going to apply this patch for 5.10 unless Bjorn would rather route it
> through the PCI tree.
Any chance we can get this into stable at some point as well? It would be nice
to fix the laptops out there in the wild running older kernels.
Alex
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
RE: [PATCH] PCI/ACPI: Whitelist hotplug ports for D3 if power managed by ACPI
[AMD Public Use]
> -Original Message-
> From: Lukas Wunner
> Sent: Friday, October 2, 2020 1:10 AM
> To: Bjorn Helgaas ; Rafael J. Wysocki
> ; Len Brown
> Cc: Deucher, Alexander ; Mika Westerberg
> ; linux-...@vger.kernel.org; linux-
> a...@vger.kernel.org; amd-gfx@lists.freedesktop.org; Arthur Borsboom
> ; matoro ; Aaron
> Zakhrov ; Michal Rostecki
> ; Shai Coleman
> Subject: [PATCH] PCI/ACPI: Whitelist hotplug ports for D3 if power managed
> by ACPI
>
> Recent laptops with dual AMD GPUs fail to suspend the discrete GPU, thus
> causing lockups on system sleep and high power consumption at runtime.
> The discrete GPU would normally be suspended to D3cold by turning off
> ACPI _PR3 Power Resources of the Root Port above the GPU.
>
> However on affected systems, the Root Port is hotplug-capable and
> pci_bridge_d3_possible() only allows hotplug ports to go to D3 if they belong
> to a Thunderbolt device or if the Root Port possesses a
> "HotPlugSupportInD3" ACPI property. Neither is the case on affected
> laptops. The reason for whitelisting only specific, known to work hotplug
> ports for D3 is that there have been reports of SkyLake Xeon-SP systems
> raising Hardware Error NMIs upon suspending their hotplug ports:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.
> kernel.org%2Flinux-pci%2F20170503180426.GA4058%40otc-nc-
> 03%2Fdata=02%7C01%7Calexander.deucher%40amd.com%7C712c82d
> abd82477e540408d8669172c3%7C3dd8961fe4884e608e11a82d994e183d%7C0
> %7C0%7C637372123238938344sdata=S1%2ByqWpkuZcilrl7kRXQyodrN
> P66MAjcECRDd7tEjpE%3Dreserved=0
>
> But if a hotplug port is power manageable by ACPI (as can be detected
> through presence of Power Resources and corresponding _PS0 and _PS3
> methods) then it ought to be safe to suspend it to D3. To this end, amend
> acpi_pci_bridge_d3() to whitelist such ports for D3.
>
> Link:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitla
> b.freedesktop.org%2Fdrm%2Famd%2F-
> %2Fissues%2F1222data=02%7C01%7Calexander.deucher%40amd.com
> %7C712c82dabd82477e540408d8669172c3%7C3dd8961fe4884e608e11a82d99
> 4e183d%7C0%7C0%7C637372123238938344sdata=k%2FRI8kSJclwhzYuc
> WSjAZNzNEaaU9JgIYNjJsV0dAWo%3Dreserved=0
> Link:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitla
> b.freedesktop.org%2Fdrm%2Famd%2F-
> %2Fissues%2F1252data=02%7C01%7Calexander.deucher%40amd.com
> %7C712c82dabd82477e540408d8669172c3%7C3dd8961fe4884e608e11a82d99
> 4e183d%7C0%7C0%7C637372123238938344sdata=JvakgHaQNI6XMaM
> eTHqtPJ5ooZP83lN%2F6wcdHyt53yA%3Dreserved=0
> Link:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitla
> b.freedesktop.org%2Fdrm%2Famd%2F-
> %2Fissues%2F1304data=02%7C01%7Calexander.deucher%40amd.com
> %7C712c82dabd82477e540408d8669172c3%7C3dd8961fe4884e608e11a82d99
> 4e183d%7C0%7C0%7C637372123238938344sdata=8clLa%2BCnwH4xtK
> Dc7F9%2FqPBSMFygpjP8EiPgVIz9LiE%3Dreserved=0
> Reported-and-tested-by: Arthur Borsboom
> Reported-and-tested-by: matoro
> Reported-by: Aaron Zakhrov
> Reported-by: Michal Rostecki
> Reported-by: Shai Coleman
> Signed-off-by: Lukas Wunner
> Cc: sta...@vger.kernel.org
> Cc: Alex Deucher
> Cc: Rafael J. Wysocki
> Cc: Mika Westerberg
Thanks for sorting this out.
Acked-by: Alex Deucher
> ---
> drivers/pci/pci-acpi.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c index
> d5869a0..d9aa551 100644
> --- a/drivers/pci/pci-acpi.c
> +++ b/drivers/pci/pci-acpi.c
> @@ -944,6 +944,16 @@ static bool acpi_pci_bridge_d3(struct pci_dev *dev)
> if (!dev->is_hotplug_bridge)
> return false;
>
> + /* Assume D3 support if the bridge is power-manageable by ACPI. */
> + adev = ACPI_COMPANION(>dev);
> + if (!adev && !pci_dev_is_added(dev)) {
> + adev = acpi_pci_find_companion(>dev);
> + ACPI_COMPANION_SET(>dev, adev);
> + }
> +
> + if (adev && acpi_device_power_manageable(adev))
> + return true;
> +
> /*
>* Look for a special _DSD property for the root port and if it
>* is set we know the hierarchy behind it supports D3 just fine.
> --
> 2.27.0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amd/pm: fix screen flicker seen on Navi14 with 2*4K monitors
[AMD Official Use Only - Internal Distribution Only]
Thanks.
Acked-by: Alex Deucher
From: Quan, Evan
Sent: Thursday, September 24, 2020 11:38 PM
To: Alex Deucher
Cc: amd-gfx list ; Deucher, Alexander
Subject: RE: [PATCH] drm/amd/pm: fix screen flicker seen on Navi14 with 2*4K
monitors
[AMD Official Use Only - Internal Distribution Only]
That(postpone SOCCLK/UCLK enablement) will be revised and added back after
confirmed with DAL team.
For now, we just revert it to get around the screen flicker issue introduced.
BR
Evan
-Original Message-
From: Alex Deucher
Sent: Thursday, September 24, 2020 9:01 PM
To: Quan, Evan
Cc: amd-gfx list ; Deucher, Alexander
Subject: Re: [PATCH] drm/amd/pm: fix screen flicker seen on Navi14 with 2*4K
monitors
On Thu, Sep 24, 2020 at 6:10 AM Evan Quan wrote:
>
> Revert the guilty change introduced by the commit below:
> drm/amd/pm: postpone SOCCLK/UCLK enablement after DAL
> initialization(V2)
>
> Change-Id: I0cab619ffdf0f83b14ba5d2907e1b9c02a984e2f
> Signed-off-by: Evan Quan
Won't this effectively disable the potential fix for multiple monitors at boot
time?
Acked-by: Alex Deucher
> ---
> .../gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c | 43 ++-
> 1 file changed, 12 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
> b/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
> index 1695b36dc23c..be44cb941e73 100644
> --- a/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
> +++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
> @@ -316,6 +316,18 @@ navi10_get_allowed_feature_mask(struct smu_context *smu,
> if (smu->dc_controlled_by_gpio)
> *(uint64_t *)feature_mask |=
> FEATURE_MASK(FEATURE_ACDC_BIT);
>
> + if (adev->pm.pp_feature & PP_SOCCLK_DPM_MASK)
> + *(uint64_t *)feature_mask |=
> + FEATURE_MASK(FEATURE_DPM_SOCCLK_BIT);
> +
> + /* DPM UCLK enablement should be skipped for navi10 A0 secure board */
> + if (!(is_asic_secure(smu) &&
> +(adev->asic_type == CHIP_NAVI10) &&
> +(adev->rev_id == 0)) &&
> + (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);
> +
> /* DS SOCCLK enablement should be skipped for navi10 A0 secure board
> */
> if (is_asic_secure(smu) &&
> (adev->asic_type == CHIP_NAVI10) && @@ -2629,43 +2641,12
> @@ static int navi10_enable_mgpu_fan_boost(struct smu_context *smu)
>
> static int navi10_post_smu_init(struct smu_context *smu) {
> - struct smu_feature *feature = >smu_feature;
> struct amdgpu_device *adev = smu->adev;
> - uint64_t feature_mask = 0;
> int ret = 0;
>
> if (amdgpu_sriov_vf(adev))
> return 0;
>
> - /* For Naiv1x, enable these features only after DAL initialization */
> - if (adev->pm.pp_feature & PP_SOCCLK_DPM_MASK)
> - feature_mask |= FEATURE_MASK(FEATURE_DPM_SOCCLK_BIT);
> -
> - /* DPM UCLK enablement should be skipped for navi10 A0 secure board */
> - if (!(is_asic_secure(smu) &&
> -(adev->asic_type == CHIP_NAVI10) &&
> -(adev->rev_id == 0)) &&
> - (adev->pm.pp_feature & PP_MCLK_DPM_MASK))
> - feature_mask |= FEATURE_MASK(FEATURE_DPM_UCLK_BIT)
> - | FEATURE_MASK(FEATURE_MEM_VDDCI_SCALING_BIT)
> - | FEATURE_MASK(FEATURE_MEM_MVDD_SCALING_BIT);
> -
> - if (!feature_mask)
> - return 0;
> -
> - bitmap_or(feature->allowed,
> - feature->allowed,
> - (unsigned long *)(_mask),
> - SMU_FEATURE_MAX);
> -
> - ret = smu_cmn_feature_update_enable_state(smu,
> - feature_mask,
> - true);
> - if (ret) {
> - dev_err(adev->dev, "Failed to post uclk/socclk dpm
> enablement!\n");
> - return ret;
> - }
> -
> ret = navi10_run_umc_cdr_workaround(smu);
> if (ret) {
> dev_err(adev->dev, "Failed to apply umc cdr
> workaround!\n");
> --
> 2.28.0
>
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedeskt
Re: [PATCH] drm/amd/pm: correct the pmfw version check for Navi14
[AMD Public Use]
Reviewed-by: Alex Deucher
From: Quan, Evan
Sent: Sunday, September 20, 2020 10:47 PM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Quan, Evan
Subject: [PATCH] drm/amd/pm: correct the pmfw version check for Navi14
Otherwise, that will be always true for Navi14.
Change-Id: Ief94150d10e4987e405d97674d9ae4efe89246fb
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
b/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
index e729337e84d0..b9e522ed499a 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
@@ -2279,13 +2279,14 @@ static int navi10_run_umc_cdr_workaround(struct
smu_context *smu)
}
/*
-* The messages below are only supported by 42.53.0 and later
-* PMFWs.
+* The messages below are only supported by Navi10 42.53.0 and later
+* PMFWs and Navi14 53.29.0 and later PMFWs.
* - PPSMC_MSG_SetDriverDummyTableDramAddrHigh
* - PPSMC_MSG_SetDriverDummyTableDramAddrLow
* - PPSMC_MSG_GetUMCFWWA
*/
- if (pmfw_version >= 0x2a3500) {
+ if (((adev->asic_type == CHIP_NAVI10) && (pmfw_version >= 0x2a3500)) ||
+ ((adev->asic_type == CHIP_NAVI14) && (pmfw_version >= 0x351D00))) {
ret = smu_cmn_send_smc_msg_with_param(smu,
SMU_MSG_GET_UMC_FW_WA,
0,
--
2.28.0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 2/2] drm/amd/pm: drop redundant watermarks bitmap setting
[AMD Public Use]
Series is:
Reviewed-by: Alex Deucher
From: Quan, Evan
Sent: Sunday, September 20, 2020 10:49 PM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Quan, Evan
Subject: [PATCH 2/2] drm/amd/pm: drop redundant watermarks bitmap setting
As this is already set inside the implementation of
smu_set_watermarks_table().
Change-Id: I4d4d40855f0aad43f6d21d471b64f1c7e696f0e7
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
index 002bae81b856..ef10be599d37 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
@@ -1838,11 +1838,6 @@ int smu_set_watermarks_for_clock_ranges(struct
smu_context *smu,
ret = smu_set_watermarks_table(smu, clock_ranges);
- if (!(smu->watermarks_bitmap & WATERMARKS_EXIST)) {
- smu->watermarks_bitmap |= WATERMARKS_EXIST;
- smu->watermarks_bitmap &= ~WATERMARKS_LOADED;
- }
-
mutex_unlock(>mutex);
return ret;
--
2.28.0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdkfd: Use kvmalloc instead of kmalloc for VCRAT
[AMD Public Use] Reviewed-by: Alex Deucher From: amd-gfx on behalf of Kent Russell Sent: Monday, September 21, 2020 10:27 AM To: amd-gfx@lists.freedesktop.org Cc: Russell, Kent Subject: [PATCH] drm/amdkfd: Use kvmalloc instead of kmalloc for VCRAT Since we're dynamically allocating the CPU VCRAT, use kvmalloc in case the allocation size is huge. Signed-off-by: Kent Russell --- drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c index 99182b8e9152..c50e9f634d6c 100644 --- a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c @@ -797,7 +797,8 @@ int kfd_create_crat_image_acpi(void **crat_image, size_t *size) return -ENODATA; } - pcrat_image = kmemdup(crat_table, crat_table->length, GFP_KERNEL); + pcrat_image = kvmalloc(crat_table->length, GFP_KERNEL); + memcpy(pcrat_image, crat_table, crat_table->length); if (!pcrat_image) return -ENOMEM; @@ -1383,7 +1384,7 @@ int kfd_create_crat_image_virtual(void **crat_image, size_t *size, num_nodes * (sizeof(struct crat_subtype_computeunit) + sizeof(struct crat_subtype_memory) + (num_nodes - 1) * sizeof(struct crat_subtype_iolink)); - pcrat_image = kmalloc(dyn_size, GFP_KERNEL); + pcrat_image = kvmalloc(dyn_size, GFP_KERNEL); if (!pcrat_image) return -ENOMEM; *size = dyn_size; @@ -1393,7 +1394,7 @@ int kfd_create_crat_image_virtual(void **crat_image, size_t *size, case COMPUTE_UNIT_GPU: if (!kdev) return -EINVAL; - pcrat_image = kmalloc(VCRAT_SIZE_FOR_GPU, GFP_KERNEL); + pcrat_image = kvmalloc(VCRAT_SIZE_FOR_GPU, GFP_KERNEL); if (!pcrat_image) return -ENOMEM; *size = VCRAT_SIZE_FOR_GPU; @@ -1412,7 +1413,7 @@ int kfd_create_crat_image_virtual(void **crat_image, size_t *size, if (!ret) *crat_image = pcrat_image; else - kfree(pcrat_image); + kvfree(pcrat_image); return ret; } -- 2.17.1 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfxdata=02%7C01%7Calexander.deucher%40amd.com%7C2c0550686c55482e784108d85e3a79b9%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637362952855598708sdata=juwKVfB3gvGU5TkLKf9KYPdy90sgT80810dh91hpZSw%3Dreserved=0 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amd/pm: apply dummy reads workaround for CDR enabled only
[AMD Official Use Only - Internal Distribution Only]
Acked-by: Alex Deucher
From: Quan, Evan
Sent: Thursday, September 17, 2020 10:36 PM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Quan, Evan
Subject: [PATCH] drm/amd/pm: apply dummy reads workaround for CDR enabled only
For CDR disabled case, the dummy reads workaround is not needed.
Change-Id: I474619b3d82792151870811c289ab311028de211
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
b/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
index 338a9fdeef6e..5b87690c1e61 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
@@ -2303,10 +2303,12 @@ static int navi10_run_umc_cdr_workaround(struct
smu_context *smu)
if (umc_fw_greater_than_v136)
return 0;
- if (umc_fw_disable_cdr && adev->asic_type == CHIP_NAVI10)
- return navi10_umc_hybrid_cdr_workaround(smu);
- else
+ if (umc_fw_disable_cdr) {
+ if (adev->asic_type == CHIP_NAVI10)
+ return navi10_umc_hybrid_cdr_workaround(smu);
+ } else {
return navi10_set_dummy_pstates_table_location(smu);
+ }
} else {
if (adev->asic_type == CHIP_NAVI10)
return navi10_umc_hybrid_cdr_workaround(smu);
--
2.28.0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amd/display: Don't log hdcp module warnings in dmesg
[AMD Official Use Only - Internal Distribution Only]
Acked-by: Alex Deucher
From: Bhawanpreet Lakha
Sent: Tuesday, September 15, 2020 5:38 PM
To: Deucher, Alexander
Cc: Siqueira, Rodrigo ; Kazlauskas, Nicholas
; amd-gfx@lists.freedesktop.org
; Lakha, Bhawanpreet
Subject: [PATCH] drm/amd/display: Don't log hdcp module warnings in dmesg
[Why]
DTM topology updates happens by default now. This results in DTM
warnings when hdcp is not even being enabled. This spams the dmesg
and doesn't effect normal display functionality so it is better to log it
using DRM_DEBUG_KMS()
[How]
Change the DRM_WARN() to DRM_DEBUG_KMS()
Signed-off-by: Bhawanpreet Lakha
---
drivers/gpu/drm/amd/display/modules/hdcp/hdcp_log.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/modules/hdcp/hdcp_log.h
b/drivers/gpu/drm/amd/display/modules/hdcp/hdcp_log.h
index d3192b9d0c3d..47f8ee2832ff 100644
--- a/drivers/gpu/drm/amd/display/modules/hdcp/hdcp_log.h
+++ b/drivers/gpu/drm/amd/display/modules/hdcp/hdcp_log.h
@@ -27,7 +27,7 @@
#define MOD_HDCP_LOG_H_
#ifdef CONFIG_DRM_AMD_DC_HDCP
-#define HDCP_LOG_ERR(hdcp, ...) DRM_WARN(__VA_ARGS__)
+#define HDCP_LOG_ERR(hdcp, ...) DRM_DEBUG_KMS(__VA_ARGS__)
#define HDCP_LOG_VER(hdcp, ...) DRM_DEBUG_KMS(__VA_ARGS__)
#define HDCP_LOG_FSM(hdcp, ...) DRM_DEBUG_KMS(__VA_ARGS__)
#define HDCP_LOG_TOP(hdcp, ...) pr_debug("[HDCP_TOP]:"__VA_ARGS__)
--
2.25.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu: Update RAS init handling
[AMD Public Use]
Also, general nit, per kernel coding style, braces should be on the same line
as the if or else, E.g.,
} else {
Alex
From: amd-gfx on behalf of Zhang,
Hawking
Sent: Friday, September 11, 2020 2:02 AM
To: Clements, John ; amd-gfx list
; Chen, Guchun
Subject: RE: [PATCH] drm/amdgpu: Update RAS init handling
[AMD Public Use]
+ {
+ dev_warn(psp->adev->dev, "RAS
Init Status: 0x%X\n", ras_cmd->ras_status);
+ }
Please remove the redundant bracket.
Other than that, the patch is
Reviewed-by: Hawking Zhang
In addition, please create another patch to move the nbio ras controller irq
source registry to sw_init, which is the consistent as what we did for other ip
blocks, register the irq source in IP sw_init funcs.
Regards,
Hawking
From: Clements, John
Sent: Friday, September 11, 2020 12:03
To: amd-gfx list ; Chen, Guchun
; Zhang, Hawking
Subject: [PATCH] drm/amdgpu: Update RAS init handling
[AMD Official Use Only - Internal Distribution Only]
Added RAS status check and tear down RAS context if RAS init fails
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 1/1] drm/amdgpu: fix a typo
[AMD Public Use]
This is not upstream, but
Acked-by: Alex Deucher
From: amd-gfx on behalf of Nirmoy Das
Sent: Tuesday, September 8, 2020 11:57 AM
To: amd-gfx@lists.freedesktop.org
Cc: Das, Nirmoy ; Kazlauskas, Nicholas
Subject: [PATCH 1/1] drm/amdgpu: fix a typo
Fixes: 9a0154630e958a2f (drm/amdgpu: Bring back support for non-upstream
FreeSync)
Signed-off-by: Nirmoy Das
---
include/uapi/drm/amdgpu_drm.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/uapi/drm/amdgpu_drm.h b/include/uapi/drm/amdgpu_drm.h
index b826f2d6efe1..d3dadf10b13d 100644
--- a/include/uapi/drm/amdgpu_drm.h
+++ b/include/uapi/drm/amdgpu_drm.h
@@ -1096,7 +1096,7 @@ struct drm_amdgpu_info_vce_clock_table {
struct drm_amdgpu_freesync {
__u32 op; /* AMDGPU_FREESYNC_FULLSCREEN_ENTER or
*/
- /* AMDGPU_FREESYNC_FULLSCREEN_ENTER */
+ /* AMDGPU_FREESYNC_FULLSCREEN_EXIT */
__u32 spare[7];
};
--
2.28.0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfxdata=02%7C01%7Calexander.deucher%40amd.com%7C7f09b7d46fde47c781cf08d8540f3bb0%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637351771962233619sdata=t9hpqDYdTNU2bKoOTiGOi3bJvRhYZqCdzVdQ3Xv8dUk%3Dreserved=0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu: Include sienna_cichlid in USBC PD FW support.
[AMD Public Use]
Reviewed-by: Alex Deucher
From: Grodzovsky, Andrey
Sent: Monday, September 14, 2020 10:32 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: Re: [PATCH] drm/amdgpu: Include sienna_cichlid in USBC PD FW support.
Ping
Andrey
On 9/10/20 2:05 PM, Andrey Grodzovsky wrote:
> Create sysfs interface also for sienna_cichlid.
>
> Signed-off-by: Andrey Grodzovsky
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
> index a7771aa..600015e 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
> @@ -178,7 +178,7 @@ static int psp_sw_init(void *handle)
>return ret;
>}
>
> - if (adev->asic_type == CHIP_NAVI10) {
> + if (adev->asic_type == CHIP_NAVI10 || adev->asic_type ==
> CHIP_SIENNA_CICHLID) {
>ret= psp_sysfs_init(adev);
>if (ret) {
>return ret;
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
RE: [PATCH v3 6/7] drm: Validate encoder->possible_crtcs
[AMD Public Use]
> -Original Message-
> From: amd-gfx On Behalf Of
> Daniel Vetter
> Sent: Monday, September 7, 2020 3:15 AM
> To: Jan Kiszka ; amd-gfx list g...@lists.freedesktop.org>; Wentland, Harry ;
> Kazlauskas, Nicholas
> Cc: dri-devel ; intel-gfx g...@lists.freedesktop.org>; Thomas Zimmermann
> ; Ville Syrjala
> Subject: Re: [PATCH v3 6/7] drm: Validate encoder->possible_crtcs
>
> On Sun, Sep 6, 2020 at 1:19 PM Jan Kiszka wrote:
> >
> > On 11.02.20 18:04, Daniel Vetter wrote:
> > > On Tue, Feb 11, 2020 at 06:22:07PM +0200, Ville Syrjala wrote:
> > >> From: Ville Syrjälä
> > >>
> > >> WARN if the encoder possible_crtcs is effectively empty or contains
> > >> bits for non-existing crtcs.
> > >>
> > >> v2: Move to drm_mode_config_validate() (Daniel)
> > >> Make the docs say we WARN when this is wrong (Daniel)
> > >> Extract full_crtc_mask()
> > >>
> > >> Cc: Thomas Zimmermann
> > >> Cc: Daniel Vetter
> > >> Signed-off-by: Ville Syrjälä
> > >
> > > When pushing the fixup needs to be applied before the validation
> > > patch here, because we don't want to anger the bisect gods.
> > >
> > > Reviewed-by: Daniel Vetter
> > >
> > > I think with the fixup we should be good enough with the existing
> > > nonsense in drivers. Fingers crossed.
> > > -Daniel
> > >
> > >
> > >> ---
> > >> drivers/gpu/drm/drm_mode_config.c | 27
> ++-
> > >> include/drm/drm_encoder.h | 2 +-
> > >> 2 files changed, 27 insertions(+), 2 deletions(-)
> > >>
> > >> diff --git a/drivers/gpu/drm/drm_mode_config.c
> > >> b/drivers/gpu/drm/drm_mode_config.c
> > >> index afc91447293a..4c1b350ddb95 100644
> > >> --- a/drivers/gpu/drm/drm_mode_config.c
> > >> +++ b/drivers/gpu/drm/drm_mode_config.c
> > >> @@ -581,6 +581,29 @@ static void
> validate_encoder_possible_clones(struct drm_encoder *encoder)
> > >> encoder->possible_clones, encoder_mask); }
> > >>
> > >> +static u32 full_crtc_mask(struct drm_device *dev) {
> > >> +struct drm_crtc *crtc;
> > >> +u32 crtc_mask = 0;
> > >> +
> > >> +drm_for_each_crtc(crtc, dev)
> > >> +crtc_mask |= drm_crtc_mask(crtc);
> > >> +
> > >> +return crtc_mask;
> > >> +}
> > >> +
> > >> +static void validate_encoder_possible_crtcs(struct drm_encoder
> > >> +*encoder) {
> > >> +u32 crtc_mask = full_crtc_mask(encoder->dev);
> > >> +
> > >> +WARN((encoder->possible_crtcs & crtc_mask) == 0 ||
> > >> + (encoder->possible_crtcs & ~crtc_mask) != 0,
> > >> + "Bogus possible_crtcs: "
> > >> + "[ENCODER:%d:%s] possible_crtcs=0x%x (full crtc mask=0x%x)\n",
> > >> + encoder->base.id, encoder->name,
> > >> + encoder->possible_crtcs, crtc_mask); }
> > >> +
> > >> void drm_mode_config_validate(struct drm_device *dev) {
> > >> struct drm_encoder *encoder;
> > >> @@ -588,6 +611,8 @@ void drm_mode_config_validate(struct
> drm_device *dev)
> > >> drm_for_each_encoder(encoder, dev)
> > >> fixup_encoder_possible_clones(encoder);
> > >>
> > >> -drm_for_each_encoder(encoder, dev)
> > >> +drm_for_each_encoder(encoder, dev) {
> > >> validate_encoder_possible_clones(encoder);
> > >> +validate_encoder_possible_crtcs(encoder);
> > >> +}
> > >> }
> > >> diff --git a/include/drm/drm_encoder.h b/include/drm/drm_encoder.h
> > >> index 3741963b9587..b236269f41ac 100644
> > >> --- a/include/drm/drm_encoder.h
> > >> +++ b/include/drm/drm_encoder.h
> > >> @@ -142,7 +142,7 @@ struct drm_encoder {
> > >> * the bits for all _crtc objects this encoder can be connected
> > >> to
> > >> * before calling drm_dev_register().
> > >> *
> > >> - * In reality almost every driver gets this wrong.
> > >> + * You will get a WARN if you get this wrong in the driver.
> > >> *
> > >> * Note that since CRTC objects can't be hotplugged the assigned
> indices
> > >> * are stable and hence known before registering all objects.
> > >> --
> > >> 2.24.1
> > >>
> > >
> >
> > Triggers on an Advantech AIMB-228 (R1505G, 3 DP outputs):
>
> Adding amdgpu display folks.
I took a quick look at this and it looks like we limit the number of crtcs
later in the mode init process if the number of physical displays can't
actually use more crtcs. E.g., the physical board configuration would only
allow for 3 active displays even if the hardware technically supports 4 crtcs.
I presume that way we can just leave the additional hardware power gated all
the time.
Alex
> -Daniel
>
> >
> > [ 14.033246] [ cut here ]
> > [ 14.033248] Bogus possible_crtcs: [ENCODER:65:TMDS-65]
> possible_crtcs=0xf (full crtc mask=0x7)
> > [ 14.033279] WARNING: CPU: 0 PID: 282 at
> ../drivers/gpu/drm/drm_mode_config.c:622
> drm_mode_config_validate+0x17d/0x200 [drm]
> > [ 14.033279] Modules linked in: amdgpu(E+) mfd_core(E)
> snd_hda_codec_realtek(E) kvm_amd(E) gpu_sched(E) i2c_algo_bit(E) ttm(E)
>
Re: [PATCH] drm/amdgpu: add ta firmware load in psp_v12_0 for renoir
Reviewed-by: Alex Deucher
From: Zhu, Changfeng
Sent: Thursday, September 3, 2020 11:19 AM
To: Lakha, Bhawanpreet ; Deucher, Alexander
; amd-gfx@lists.freedesktop.org
; Huang, Ray
Subject: RE: [PATCH] drm/amdgpu: add ta firmware load in psp_v12_0 for renoir
[AMD Public Use]
[AMD Public Use]
Thanks, Lakha.
BR,
Changfeng.
From: Lakha, Bhawanpreet
Sent: Thursday, September 3, 2020 11:07 PM
To: Deucher, Alexander ; Zhu, Changfeng
; amd-gfx@lists.freedesktop.org; Huang, Ray
Subject: Re: [PATCH] drm/amdgpu: add ta firmware load in psp_v12_0 for renoir
[AMD Public Use]
Hi Alex,
psp_sw_fini() releases the ta firmware
Reviewed-by: Bhawanpreet Lakha
mailto:bhawanpreet.la...@amd.com>>
From: Deucher, Alexander
mailto:alexander.deuc...@amd.com>>
Sent: September 2, 2020 10:18 AM
To: Zhu, Changfeng mailto:changfeng@amd.com>>;
amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>
mailto:amd-gfx@lists.freedesktop.org>>; Huang,
Ray mailto:ray.hu...@amd.com>>; Lakha, Bhawanpreet
mailto:bhawanpreet.la...@amd.com>>
Subject: Re: [PATCH] drm/amdgpu: add ta firmware load in psp_v12_0 for renoir
[AMD Public Use]
We also need to release the firmware when the driver unloads or is that already
handled in some common path?
Alex
From: amd-gfx
mailto:amd-gfx-boun...@lists.freedesktop.org>>
on behalf of Changfeng.Zhu
mailto:changfeng@amd.com>>
Sent: Tuesday, September 1, 2020 10:25 PM
To: amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>
mailto:amd-gfx@lists.freedesktop.org>>; Huang,
Ray mailto:ray.hu...@amd.com>>; Lakha, Bhawanpreet
mailto:bhawanpreet.la...@amd.com>>
Cc: Zhu, Changfeng mailto:changfeng@amd.com>>
Subject: [PATCH] drm/amdgpu: add ta firmware load in psp_v12_0 for renoir
From: changzhu mailto:changfeng@amd.com>>
From: Changfeng mailto:changfeng@amd.com>>
It needs to load renoir_ta firmware because hdcp is enabled by default
for renoir now. This can avoid error:DTM TA is not initialized
Change-Id: Ib2f03a531013e4b432c2e9d4ec3dc021b4f8da7d
Signed-off-by: Changfeng mailto:changfeng@amd.com>>
---
drivers/gpu/drm/amd/amdgpu/psp_v12_0.c | 54 ++
1 file changed, 54 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/psp_v12_0.c
b/drivers/gpu/drm/amd/amdgpu/psp_v12_0.c
index 6c9614f77d33..75489313dbad 100644
--- a/drivers/gpu/drm/amd/amdgpu/psp_v12_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/psp_v12_0.c
@@ -38,6 +38,8 @@
#include "oss/osssys_4_0_sh_mask.h"
MODULE_FIRMWARE("amdgpu/renoir_asd.bin");
+MODULE_FIRMWARE("amdgpu/renoir_ta.bin");
+
/* address block */
#define smnMP1_FIRMWARE_FLAGS 0x3010024
@@ -45,7 +47,10 @@ static int psp_v12_0_init_microcode(struct psp_context *psp)
{
struct amdgpu_device *adev = psp->adev;
const char *chip_name;
+ char fw_name[30];
int err = 0;
+ const struct ta_firmware_header_v1_0 *ta_hdr;
+ DRM_DEBUG("\n");
switch (adev->asic_type) {
case CHIP_RENOIR:
@@ -56,6 +61,55 @@ static int psp_v12_0_init_microcode(struct psp_context *psp)
}
err = psp_init_asd_microcode(psp, chip_name);
+ if (err)
+ goto out;
+
+ snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_ta.bin", chip_name);
+ err = request_firmware(>psp.ta_fw, fw_name, adev->dev);
+ if (err) {
+ release_firmware(adev->psp.ta_fw);
+ adev->psp.ta_fw = NULL;
+ dev_info(adev->dev,
+"psp v12.0: Failed to load firmware \"%s\"\n",
+fw_name);
+ } else {
+ err = amdgpu_ucode_validate(adev->psp.ta_fw);
+ if (err)
+ goto out2;
+
+ ta_hdr = (const struct ta_firmware_header_v1_0 *)
+adev->psp.ta_fw->data;
+ adev->psp.ta_hdcp_ucode_version =
+ le32_to_cpu(ta_hdr->ta_hdcp_ucode_version);
+ adev->psp.ta_hdcp_ucode_size =
+ le32_to_cpu(ta_hdr->ta_hdcp_size_bytes);
+ adev->psp.ta_hdcp_start_addr =
+ (uint8_t *)ta_hdr +
+ le32_to_cpu(ta_hdr->header.ucode_array_offset_bytes);
+
+ adev->psp.ta_fw_version =
le32_to_cpu(ta_hdr->header.ucode_version);
+
+ adev->psp.ta_dtm_ucode_version =
+ le32_to_cpu(ta_hdr->ta_dtm_ucode_version);
+ adev->psp.ta_dtm_ucode_size =
+ le32_to_cpu(ta_hdr->ta_dtm_size_bytes);
+ adev->psp.ta_dt
Re: [PATCH v4 0/8] Implement PCI Error Recovery on Navi12
[AMD Official Use Only - Internal Distribution Only] I'll push an updated branch shortly. Alex From: Grodzovsky, Andrey Sent: Thursday, September 3, 2020 11:01 AM To: Bjorn Helgaas Cc: amd-gfx@lists.freedesktop.org ; sathyanarayanan.kuppusw...@linux.intel.com ; linux-...@vger.kernel.org ; Deucher, Alexander ; Das, Nirmoy ; Li, Dennis ; Koenig, Christian ; Tuikov, Luben ; bhelg...@google.com Subject: Re: [PATCH v4 0/8] Implement PCI Error Recovery on Navi12 This one is very close - https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-drm-next Andrey On 9/2/20 8:41 PM, Bjorn Helgaas wrote: > On Wed, Sep 02, 2020 at 11:43:41PM +, Grodzovsky, Andrey wrote: >> It's based on v5.9-rc2 but won't apply cleanly since there is a >> significant amount of amd-staging-drm-next patches which this was >> applied on top of. > Is there a git branch published somewhere? It'd be nice to be able to > see the whole thing, including the bits that this depends on from > amd-staging-drm-next. ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 2/2] drm/amdgpu/gmc10: print client id string for gfxhub
[AMD Official Use Only - Internal Distribution Only]
I'm working on the mmhub clients list. Will send out patches for them soon.
Alex
From: Christian König
Sent: Wednesday, September 2, 2020 3:17 AM
To: Kuehling, Felix ; Alex Deucher
; amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: Re: [PATCH 2/2] drm/amdgpu/gmc10: print client id string for gfxhub
Am 02.09.20 um 04:32 schrieb Felix Kuehling:
> Should there a corresponding change in mmhub_v2_0.c?
It would be at least nice to have.
Maybe we should put a pointer to the array and its size into the hub
structure instead?
Anyway Reviewed-by: Christian König for now.
Christian.
>
> Other than that, the series is
>
> Reviewed-by: Felix Kuehling
>
> On 2020-09-01 5:51 p.m., Alex Deucher wrote:
>> Print the name of the client rather than the number. This
>> makes it easier to debug what block is causing the fault.
>>
>> Signed-off-by: Alex Deucher
>> ---
>> drivers/gpu/drm/amd/amdgpu/gfxhub_v2_0.c | 30 +---
>> drivers/gpu/drm/amd/amdgpu/gfxhub_v2_1.c | 30 +---
>> 2 files changed, 54 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/gfxhub_v2_0.c
>> b/drivers/gpu/drm/amd/amdgpu/gfxhub_v2_0.c
>> index 76acd7f7723e..b882ac59879a 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/gfxhub_v2_0.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/gfxhub_v2_0.c
>> @@ -31,6 +31,27 @@
>> #include "soc15_common.h"
>> +static const char *gfxhub_client_ids[] = {
>> +"CB/DB",
>> +"Reserved",
>> +"GE1",
>> +"GE2",
>> +"CPF",
>> +"CPC",
>> +"CPG",
>> +"RLC",
>> +"TCP",
>> +"SQC (inst)",
>> +"SQC (data)",
>> +"SQG",
>> +"Reserved",
>> +"SDMA0",
>> +"SDMA1",
>> +"GCR",
>> +"SDMA2",
>> +"SDMA3",
>> +};
>> +
>> static uint32_t gfxhub_v2_0_get_invalidate_req(unsigned int vmid,
>> uint32_t flush_type)
>> {
>> @@ -55,12 +76,15 @@ static void
>> gfxhub_v2_0_print_l2_protection_fault_status(struct amdgpu_device
>> *adev,
>>uint32_t status)
>> {
>> +u32 cid = REG_GET_FIELD(status,
>> +GCVM_L2_PROTECTION_FAULT_STATUS, CID);
>> +
>> dev_err(adev->dev,
>> "GCVM_L2_PROTECTION_FAULT_STATUS:0x%08X\n",
>> status);
>> -dev_err(adev->dev, "\t Faulty UTCL2 client ID: 0x%lx\n",
>> -REG_GET_FIELD(status,
>> -GCVM_L2_PROTECTION_FAULT_STATUS, CID));
>> +dev_err(adev->dev, "\t Faulty UTCL2 client ID: %s (0x%x)\n",
>> +cid >= ARRAY_SIZE(gfxhub_client_ids) ? "unknown" :
>> gfxhub_client_ids[cid],
>> +cid);
>> dev_err(adev->dev, "\t MORE_FAULTS: 0x%lx\n",
>> REG_GET_FIELD(status,
>> GCVM_L2_PROTECTION_FAULT_STATUS, MORE_FAULTS));
>> diff --git a/drivers/gpu/drm/amd/amdgpu/gfxhub_v2_1.c
>> b/drivers/gpu/drm/amd/amdgpu/gfxhub_v2_1.c
>> index 80c906a0383f..237a9ff5afa0 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/gfxhub_v2_1.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/gfxhub_v2_1.c
>> @@ -31,6 +31,27 @@
>> #include "soc15_common.h"
>> +static const char *gfxhub_client_ids[] = {
>> +"CB/DB",
>> +"Reserved",
>> +"GE1",
>> +"GE2",
>> +"CPF",
>> +"CPC",
>> +"CPG",
>> +"RLC",
>> +"TCP",
>> +"SQC (inst)",
>> +"SQC (data)",
>> +"SQG",
>> +"Reserved",
>> +"SDMA0",
>> +"SDMA1",
>> +"GCR",
>> +"SDMA2",
>> +"SDMA3",
>> +};
>> +
>> static uint32_t gfxhub_v2_1_get_invalidate_req(unsigned int vmid,
>> uint32_t flush_type)
>> {
>> @@ -55,12 +76,15 @@ static void
>> gfxhub_v2_1_print_l2_protection_fault_status(struct amdgpu_device
>> *adev,
>>uint32_t status)
>> {
>> +u32 cid = REG_GET_FIELD(status,
>> +GCVM_L2_PROTECTION_FAULT_STATUS, CID);
>> +
>>
Re: [PATCH] drm/amdgpu: fix max_entries calculation v2
[AMD Official Use Only - Internal Distribution Only]
Acked-by: Alex Deucher
From: amd-gfx on behalf of Christian
König
Sent: Wednesday, September 2, 2020 10:05 AM
To: Pan, Xinhui ; amd-gfx@lists.freedesktop.org
Subject: [PATCH] drm/amdgpu: fix max_entries calculation v2
Calculate the correct value for max_entries or we might run after the
page_address array.
v2: Xinhui pointed out we don't need the shift
Signed-off-by: Christian König
Fixes: 1e691e244487 drm/amdgpu: stop allocating dummy GTT nodes
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 8bc2253939be..be886bdca5c6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -1697,7 +1697,7 @@ static int amdgpu_vm_bo_split_mapping(struct
amdgpu_device *adev,
AMDGPU_GPU_PAGES_IN_CPU_PAGE;
} else {
addr = 0;
- max_entries = S64_MAX;
+ max_entries = mapping->last - mapping->start + 1;
}
if (pages_addr) {
--
2.17.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfxdata=02%7C01%7Calexander.deucher%40amd.com%7Ce5239f6d94a9480e27e008d84f4939b5%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637346523216694548sdata=OF7UX%2FLbWPJXkymt1QsdVVrQCZxI2Avj%2BBv1HYWPzxo%3Dreserved=0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu: add ta firmware load in psp_v12_0 for renoir
[AMD Public Use]
We also need to release the firmware when the driver unloads or is that already
handled in some common path?
Alex
From: amd-gfx on behalf of
Changfeng.Zhu
Sent: Tuesday, September 1, 2020 10:25 PM
To: amd-gfx@lists.freedesktop.org ; Huang, Ray
; Lakha, Bhawanpreet
Cc: Zhu, Changfeng
Subject: [PATCH] drm/amdgpu: add ta firmware load in psp_v12_0 for renoir
From: changzhu
From: Changfeng
It needs to load renoir_ta firmware because hdcp is enabled by default
for renoir now. This can avoid error:DTM TA is not initialized
Change-Id: Ib2f03a531013e4b432c2e9d4ec3dc021b4f8da7d
Signed-off-by: Changfeng
---
drivers/gpu/drm/amd/amdgpu/psp_v12_0.c | 54 ++
1 file changed, 54 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/psp_v12_0.c
b/drivers/gpu/drm/amd/amdgpu/psp_v12_0.c
index 6c9614f77d33..75489313dbad 100644
--- a/drivers/gpu/drm/amd/amdgpu/psp_v12_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/psp_v12_0.c
@@ -38,6 +38,8 @@
#include "oss/osssys_4_0_sh_mask.h"
MODULE_FIRMWARE("amdgpu/renoir_asd.bin");
+MODULE_FIRMWARE("amdgpu/renoir_ta.bin");
+
/* address block */
#define smnMP1_FIRMWARE_FLAGS 0x3010024
@@ -45,7 +47,10 @@ static int psp_v12_0_init_microcode(struct psp_context *psp)
{
struct amdgpu_device *adev = psp->adev;
const char *chip_name;
+ char fw_name[30];
int err = 0;
+ const struct ta_firmware_header_v1_0 *ta_hdr;
+ DRM_DEBUG("\n");
switch (adev->asic_type) {
case CHIP_RENOIR:
@@ -56,6 +61,55 @@ static int psp_v12_0_init_microcode(struct psp_context *psp)
}
err = psp_init_asd_microcode(psp, chip_name);
+ if (err)
+ goto out;
+
+ snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_ta.bin", chip_name);
+ err = request_firmware(>psp.ta_fw, fw_name, adev->dev);
+ if (err) {
+ release_firmware(adev->psp.ta_fw);
+ adev->psp.ta_fw = NULL;
+ dev_info(adev->dev,
+"psp v12.0: Failed to load firmware \"%s\"\n",
+fw_name);
+ } else {
+ err = amdgpu_ucode_validate(adev->psp.ta_fw);
+ if (err)
+ goto out2;
+
+ ta_hdr = (const struct ta_firmware_header_v1_0 *)
+adev->psp.ta_fw->data;
+ adev->psp.ta_hdcp_ucode_version =
+ le32_to_cpu(ta_hdr->ta_hdcp_ucode_version);
+ adev->psp.ta_hdcp_ucode_size =
+ le32_to_cpu(ta_hdr->ta_hdcp_size_bytes);
+ adev->psp.ta_hdcp_start_addr =
+ (uint8_t *)ta_hdr +
+ le32_to_cpu(ta_hdr->header.ucode_array_offset_bytes);
+
+ adev->psp.ta_fw_version =
le32_to_cpu(ta_hdr->header.ucode_version);
+
+ adev->psp.ta_dtm_ucode_version =
+ le32_to_cpu(ta_hdr->ta_dtm_ucode_version);
+ adev->psp.ta_dtm_ucode_size =
+ le32_to_cpu(ta_hdr->ta_dtm_size_bytes);
+ adev->psp.ta_dtm_start_addr =
+ (uint8_t *)adev->psp.ta_hdcp_start_addr +
+ le32_to_cpu(ta_hdr->ta_dtm_offset_bytes);
+ }
+
+ return 0;
+
+out2:
+ release_firmware(adev->psp.ta_fw);
+ adev->psp.ta_fw = NULL;
+out:
+ if (err) {
+ dev_err(adev->dev,
+ "psp v12.0: Failed to load firmware \"%s\"\n",
+ fw_name);
+ }
+
return err;
}
--
2.17.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfxdata=02%7C01%7Calexander.deucher%40amd.com%7C324a6285d81146a0639b08d84ee78d14%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637346103730596780sdata=ItQDVbjEzkmKeeEU%2BV01rQb4iGuWvHaqRAFlC4e6oqI%3Dreserved=0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 1/4] drm/amd/pm: drop unnecessary feature->mutex lock protections(V2)
[AMD Official Use Only - Internal Distribution Only] This code gets called during suspend and resume and GPU reset as well. Are those cases properly covered? Alex From: amd-gfx on behalf of Christian König Sent: Friday, August 28, 2020 4:16 AM To: Das, Nirmoy ; amd-gfx@lists.freedesktop.org Subject: Re: [PATCH 1/4] drm/amd/pm: drop unnecessary feature->mutex lock protections(V2) The explanation sounds sane, but since I don't know the affected code at all the series is only Acked-by: Christian König Maybe wait for Alex to give you an rb if you are unsure, otherwise feel free to commit. Christian. Am 27.08.20 um 08:39 schrieb Nirmoy: > Series is Acked-by: Nirmoy Das > > > On 8/25/20 9:49 AM, Evan Quan wrote: >> As these operations are performed in hardware setup and there >> is actually no race conditions during this period considering: >> 1. the hardware setup is serial and cannnot be in parallel >> 2. all other operations can be performed only after hardware >> setup complete. >> >> V2: rich the commit log description >> >> Change-Id: I096d7ab0855ff59b0ecb56fd9d6d9946b3605fc8 >> Signed-off-by: Evan Quan >> --- >> drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 4 >> drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c | 2 -- >> 2 files changed, 6 deletions(-) >> >> diff --git a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c >> b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c >> index 09dc5303762b..b7cad8ef6153 100644 >> --- a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c >> +++ b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c >> @@ -361,20 +361,16 @@ static int >> smu_get_driver_allowed_feature_mask(struct smu_context *smu) >> int ret = 0; >> uint32_t allowed_feature_mask[SMU_FEATURE_MAX/32]; >> -mutex_lock(>mutex); >> bitmap_zero(feature->allowed, SMU_FEATURE_MAX); >> -mutex_unlock(>mutex); >> ret = smu_get_allowed_feature_mask(smu, allowed_feature_mask, >>SMU_FEATURE_MAX/32); >> if (ret) >> return ret; >> -mutex_lock(>mutex); >> bitmap_or(feature->allowed, feature->allowed, >> (unsigned long *)allowed_feature_mask, >> feature->feature_num); >> -mutex_unlock(>mutex); >> return ret; >> } >> diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c >> b/drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c >> index 548db1edd352..28a19ffd22a1 100644 >> --- a/drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c >> +++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c >> @@ -721,7 +721,6 @@ int smu_v11_0_set_allowed_mask(struct smu_context >> *smu) >> int ret = 0; >> uint32_t feature_mask[2]; >> -mutex_lock(>mutex); >> if (bitmap_empty(feature->allowed, SMU_FEATURE_MAX) || >> feature->feature_num < 64) >> goto failed; >> @@ -738,7 +737,6 @@ int smu_v11_0_set_allowed_mask(struct >> smu_context *smu) >> goto failed; >> failed: >> -mutex_unlock(>mutex); >> return ret; >> } > ___ > amd-gfx mailing list > amd-gfx@lists.freedesktop.org > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfxdata=02%7C01%7Calexander.deucher%40amd.com%7Ccad2767c7837431f94f308d84b2ab750%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637341994162774368sdata=b8PVt6zfQJXYlVunpFMY12knU8ZlJ7UE0ojZjhAWJdY%3Dreserved=0 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfxdata=02%7C01%7Calexander.deucher%40amd.com%7Ccad2767c7837431f94f308d84b2ab750%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637341994162774368sdata=b8PVt6zfQJXYlVunpFMY12knU8ZlJ7UE0ojZjhAWJdY%3Dreserved=0 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 1/1] drm/amdgpu: fix compiler warnings
[AMD Official Use Only - Internal Distribution Only]
Reviewed-by: Alex Deucher
From: Das, Nirmoy
Sent: Thursday, August 27, 2020 11:58 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Das, Nirmoy
Subject: [PATCH 1/1] drm/amdgpu: fix compiler warnings
Fixes below compiler warnings:
CC [M] drivers/gpu/drm/amd/amdgpu/amdgpu_device.o
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:381:1: warning: ‘static’ is not at
beginning of declaration [-Wold-style-declaration]
381 | void static inline amdgpu_mm_wreg_mmio(struct amdgpu_device *adev,
uint32_t reg, uint32_t v, uint32_t acc_flags)
| ^~~~
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:381:1: warning: ‘inline’ is not at
beginning of declaration [-Wold-style-declaration]
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c: In function ‘amdgpu_device_fini’:
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:3381:6: warning: variable ‘r’ set
but not used [-Wunused-but-set-variable]
3381 | int r;
| ^
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 696a61cc3ac6..6518e444bead 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -378,7 +378,9 @@ void amdgpu_mm_wreg8(struct amdgpu_device *adev, uint32_t
offset, uint8_t value)
BUG();
}
-void static inline amdgpu_mm_wreg_mmio(struct amdgpu_device *adev, uint32_t
reg, uint32_t v, uint32_t acc_flags)
+static inline void amdgpu_mm_wreg_mmio(struct amdgpu_device *adev,
+ uint32_t reg, uint32_t v,
+ uint32_t acc_flags)
{
trace_amdgpu_mm_wreg(adev->pdev->device, reg, v);
@@ -3378,8 +3380,6 @@ int amdgpu_device_init(struct amdgpu_device *adev,
*/
void amdgpu_device_fini(struct amdgpu_device *adev)
{
- int r;
-
dev_info(adev->dev, "amdgpu: finishing device.\n");
flush_delayed_work(>delayed_init_work);
adev->shutdown = true;
@@ -3402,7 +3402,7 @@ void amdgpu_device_fini(struct amdgpu_device *adev)
if (adev->pm_sysfs_en)
amdgpu_pm_sysfs_fini(adev);
amdgpu_fbdev_fini(adev);
- r = amdgpu_device_ip_fini(adev);
+ amdgpu_device_ip_fini(adev);
release_firmware(adev->firmware.gpu_info_fw);
adev->firmware.gpu_info_fw = NULL;
adev->accel_working = false;
--
2.28.0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amd/pm: avoid false alarm due to confusing softwareshutdowntemp setting
[AMD Official Use Only - Internal Distribution Only]
Acked-by: Alex Deucher
From: Quan, Evan
Sent: Wednesday, August 26, 2020 3:45 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Quan, Evan
Subject: [PATCH] drm/amd/pm: avoid false alarm due to confusing
softwareshutdowntemp setting
Normally softwareshutdowntemp should be greater than Thotspotlimit.
However, on some VEGA10 ASIC, the softwareshutdowntemp is 91C while
Thotspotlimit is 105C. This seems not right and may trigger some
false alarms.
Change-Id: I940cc6e450eebccd93ccdc3428187f6b7c09dcda
Signed-off-by: Evan Quan
---
.../drm/amd/pm/powerplay/hwmgr/vega10_thermal.c| 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_thermal.c
b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_thermal.c
index d572ba4ec9b1..952cd3d7240e 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_thermal.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_thermal.c
@@ -374,8 +374,18 @@ static int vega10_thermal_set_temperature_range(struct
pp_hwmgr *hwmgr,
/* compare them in unit celsius degree */
if (low < range->min / PP_TEMPERATURE_UNITS_PER_CENTIGRADES)
low = range->min / PP_TEMPERATURE_UNITS_PER_CENTIGRADES;
- if (high > tdp_table->usSoftwareShutdownTemp)
- high = tdp_table->usSoftwareShutdownTemp;
+
+ /*
+* As a common sense, usSoftwareShutdownTemp should be bigger
+* than ThotspotLimit. For any invalid usSoftwareShutdownTemp,
+* we will just use the max possible setting
VEGA10_THERMAL_MAXIMUM_ALERT_TEMP
+* to avoid false alarms.
+*/
+ if ((tdp_table->usSoftwareShutdownTemp >
+range->hotspot_crit_max / PP_TEMPERATURE_UNITS_PER_CENTIGRADES)) {
+ if (high > tdp_table->usSoftwareShutdownTemp)
+ high = tdp_table->usSoftwareShutdownTemp;
+ }
if (low > high)
return -EINVAL;
--
2.28.0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amd/pm: suppress static checker warning
[AMD Official Use Only - Internal Distribution Only]
Reviewed-by: Alex Deucher
From: Quan, Evan
Sent: Tuesday, August 25, 2020 11:32 PM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; dan.carpen...@oracle.com
; Quan, Evan
Subject: [PATCH] drm/amd/pm: suppress static checker warning
Suppress the warning below:
drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/hardwaremanager.c:274
phm_check_smc_update_required_for_display_configuration()
warn: signedness bug returning '(-22)'
Change-Id: If50e39fe401c16d981d917ef7d8d5ea81d6538df
Reported-by: Dan Carpenter
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/pm/powerplay/hwmgr/hardwaremanager.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/hardwaremanager.c
b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/hardwaremanager.c
index 9454ab50f9a1..1f9b9facdf1f 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/hardwaremanager.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/hardwaremanager.c
@@ -271,7 +271,10 @@ int phm_start_thermal_controller(struct pp_hwmgr *hwmgr)
bool phm_check_smc_update_required_for_display_configuration(struct pp_hwmgr
*hwmgr)
{
- PHM_FUNC_CHECK(hwmgr);
+ if (hwmgr == NULL ||
+ hwmgr->hwmgr_func == NULL)
+ return false;
+
if (hwmgr->pp_one_vf)
return false;
--
2.28.0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu: report DC not supported if virtual display is enabled
[AMD Public Use] I can do that. Alex From: Chen, Guchun Sent: Tuesday, August 25, 2020 10:13 AM To: Alex Deucher ; amd-gfx@lists.freedesktop.org Cc: Deucher, Alexander Subject: RE: [PATCH] drm/amdgpu: report DC not supported if virtual display is enabled [AMD Public Use] Why not merging it to the same line of SRIOV check? if (amdgpu_sriov_vf(adev) || adev->enable_virtual_display ) return false; Regards, Guchun -Original Message- From: amd-gfx On Behalf Of Alex Deucher Sent: Tuesday, August 25, 2020 9:45 PM To: amd-gfx@lists.freedesktop.org Cc: Deucher, Alexander Subject: [PATCH] drm/amdgpu: report DC not supported if virtual display is enabled virtual display is non-atomic so report false to avoid checking atomic state and other atomic things at runtime. Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c index 5a948edcc93c..19f1e8449986 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c @@ -2864,6 +2864,9 @@ bool amdgpu_device_has_dc_support(struct amdgpu_device *adev) if (amdgpu_sriov_vf(adev)) return false; + if (adev->enable_virtual_display) + return false; + return amdgpu_device_asic_has_dc_support(adev->asic_type); } -- 2.25.4 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfxdata=02%7C01%7Cguchun.chen%40amd.com%7C6679ea962a8a4b5715cf08d848fd2469%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637339599368934081sdata=WMMrhLJ2qXKEr6gHMn0ydF2%2B3jxzUEZ3azRsjkgOXZI%3Dreserved=0 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amd/display: Add DPCS regs for dcn3 link encoder
[AMD Official Use Only - Internal Distribution Only]
Acked-by: Alex Deucher
From: Bhawanpreet Lakha
Sent: Monday, August 24, 2020 11:11 AM
To: Deucher, Alexander
Cc: Siqueira, Rodrigo ; Kazlauskas, Nicholas
; amd-gfx@lists.freedesktop.org
; Lakha, Bhawanpreet
Subject: [PATCH] drm/amd/display: Add DPCS regs for dcn3 link encoder
dpcs reg are missing for dcn3 link encoder regs list, so add them.
Also remove
DPCSTX_DEBUG_CONFIG and RDPCSTX_DEBUG_CONFIG as they are unused and
cause compile errors for dcn3
Signed-off-by: Bhawanpreet Lakha
---
drivers/gpu/drm/amd/display/dc/dcn20/dcn20_link_encoder.h | 2 --
drivers/gpu/drm/amd/display/dc/dcn30/dcn30_resource.c | 1 +
2 files changed, 1 insertion(+), 2 deletions(-)
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 dcbf28dd72d4..864acd695cbb 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
@@ -231,8 +231,6 @@
SRI(RDPCSTX_PHY_FUSE3, RDPCSTX, id), \
SRI(DPCSTX_TX_CLOCK_CNTL, DPCSTX, id), \
SRI(DPCSTX_TX_CNTL, DPCSTX, id), \
- SRI(DPCSTX_DEBUG_CONFIG, DPCSTX, id), \
- SRI(RDPCSTX_DEBUG_CONFIG, RDPCSTX, id), \
SR(RDPCSTX0_RDPCSTX_SCRATCH)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_resource.c
b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_resource.c
index 957fc37b971e..8be4f21169d0 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_resource.c
@@ -491,6 +491,7 @@ static const struct dcn10_link_enc_hpd_registers
link_enc_hpd_regs[] = {
[id] = {\
LE_DCN3_REG_LIST(id), \
UNIPHY_DCN2_REG_LIST(phyid), \
+ DPCS_DCN2_REG_LIST(id), \
SRI(DP_DPHY_INTERNAL_CTRL, DP, id) \
}
--
2.17.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 1/2] drm/amdkfd: call amdgpu_amdkfd_get_unique_id directly
[AMD Official Use Only - Internal Distribution Only]
Series is:
Reviewed-by: Alex Deucher
From: amd-gfx on behalf of Felix
Kuehling
Sent: Monday, August 24, 2020 10:21 AM
To: amd-gfx@lists.freedesktop.org
Cc: Lin, Amber ; Shikre, Divya
Subject: [PATCH 1/2] drm/amdkfd: call amdgpu_amdkfd_get_unique_id directly
No need to use a function pointer because the implementation is not
ASIC-specific. This fixes missing support due to a missing function
pointer on Arcturus.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c | 1 -
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c | 1 -
drivers/gpu/drm/amd/amdkfd/kfd_device.c| 3 +--
drivers/gpu/drm/amd/include/kgd_kfd_interface.h| 4
4 files changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c
index b872cdb0b705..cef2ed767299 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c
@@ -778,5 +778,4 @@ const struct kfd2kgd_calls gfx_v10_kfd2kgd = {
get_atc_vmid_pasid_mapping_info,
.set_vm_context_page_table_base = set_vm_context_page_table_base,
.get_hive_id = amdgpu_amdkfd_get_hive_id,
- .get_unique_id = amdgpu_amdkfd_get_unique_id,
};
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c
index 64fdb6a81c47..e5592548b588 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c
@@ -729,5 +729,4 @@ const struct kfd2kgd_calls gfx_v9_kfd2kgd = {
kgd_gfx_v9_get_atc_vmid_pasid_mapping_info,
.set_vm_context_page_table_base =
kgd_gfx_v9_set_vm_context_page_table_base,
.get_hive_id = amdgpu_amdkfd_get_hive_id,
- .get_unique_id = amdgpu_amdkfd_get_unique_id,
};
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
index b15b620e731b..5ffd03685722 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
@@ -715,8 +715,7 @@ bool kgd2kfd_device_init(struct kfd_dev *kfd,
if (kfd->kfd2kgd->get_hive_id)
kfd->hive_id = kfd->kfd2kgd->get_hive_id(kfd->kgd);
- if (kfd->kfd2kgd->get_unique_id)
- kfd->unique_id = kfd->kfd2kgd->get_unique_id(kfd->kgd);
+ kfd->unique_id = amdgpu_amdkfd_get_unique_id(kfd->kgd);
if (kfd_interrupt_init(kfd)) {
dev_err(kfd_device, "Error initializing interrupts\n");
diff --git a/drivers/gpu/drm/amd/include/kgd_kfd_interface.h
b/drivers/gpu/drm/amd/include/kgd_kfd_interface.h
index a3c238c39ef5..017f97394344 100644
--- a/drivers/gpu/drm/amd/include/kgd_kfd_interface.h
+++ b/drivers/gpu/drm/amd/include/kgd_kfd_interface.h
@@ -214,8 +214,6 @@ struct tile_config {
*
* @get_hive_id: Returns hive id of current device, 0 if xgmi is not enabled
*
- * @get_unique_id: Returns uuid id of current device
- *
* This structure contains function pointers to services that the kgd driver
* provides to amdkfd driver.
*
@@ -291,8 +289,6 @@ struct kfd2kgd_calls {
uint32_t vmid, uint64_t page_table_base);
uint32_t (*read_vmid_from_vmfault_reg)(struct kgd_dev *kgd);
uint64_t (*get_hive_id)(struct kgd_dev *kgd);
- uint64_t (*get_unique_id)(struct kgd_dev *kgd);
-
};
#endif /* KGD_KFD_INTERFACE_H_INCLUDED */
--
2.28.0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfxdata=02%7C01%7Calexander.deucher%40amd.com%7Cf72e48fa1b804fd1a9bc08d84839073a%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637338757068577923sdata=GVcMLE70p%2BNa%2BfGIVokWqYOMCa2R3LXEBfoM0DWVC38%3Dreserved=0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 1/3] drm/amd/pm: correct Vega10 swctf limit setting
[AMD Official Use Only - Internal Distribution Only]
Might want to add:
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1267
with that, the series is:
Reviewed-by: Alex Deucher
From: Quan, Evan
Sent: Friday, August 21, 2020 12:42 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Quan, Evan
Subject: [PATCH 1/3] drm/amd/pm: correct Vega10 swctf limit setting
Correct the Vega10 thermal swctf limit.
Change-Id: I220c18bcb0772bfb8cb674337bac6dccafbd7698
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_thermal.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_thermal.c
b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_thermal.c
index 468bdd6f6697..ce9514c881ec 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_thermal.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_thermal.c
@@ -363,6 +363,9 @@ int vega10_thermal_get_temperature(struct pp_hwmgr *hwmgr)
static int vega10_thermal_set_temperature_range(struct pp_hwmgr *hwmgr,
struct PP_TemperatureRange *range)
{
+ struct phm_ppt_v2_information *pp_table_info =
+ (struct phm_ppt_v2_information *)(hwmgr->pptable);
+ struct phm_tdp_table *tdp_table = pp_table_info->tdp_table;
struct amdgpu_device *adev = hwmgr->adev;
int low = VEGA10_THERMAL_MINIMUM_ALERT_TEMP *
PP_TEMPERATURE_UNITS_PER_CENTIGRADES;
@@ -372,8 +375,8 @@ static int vega10_thermal_set_temperature_range(struct
pp_hwmgr *hwmgr,
if (low < range->min)
low = range->min;
- if (high > range->max)
- high = range->max;
+ if (high > tdp_table->usSoftwareShutdownTemp)
+ high = tdp_table->usSoftwareShutdownTemp;
if (low > high)
return -EINVAL;
--
2.28.0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: TTM/nouveau conflict in drm-misc-next
[AMD Public Use]
Double check for mis-merges on patches that went upstream via -fixes and -next.
Alex
From: Christian König
Sent: Tuesday, August 18, 2020 11:06 AM
To: Thomas Zimmermann ; Koenig, Christian
; Alex Deucher
Cc: Deucher, Alexander ;
amd-gfx@lists.freedesktop.org
Subject: Re: TTM/nouveau conflict in drm-misc-next
Am 17.08.20 um 08:31 schrieb Thomas Zimmermann:
Hi
Am 14.08.20 um 18:21 schrieb Koenig, Christian:
Am 14.08.2020 17:53 schrieb Alex Deucher
<mailto:alexdeuc...@gmail.com>:
On Fri, Aug 14, 2020 at 11:22 AM Christian König
<mailto:christian.koe...@amd.com> wrote:
>
> Hey Thomas & Alex,
>
> well the TTM and Nouveau changes look good to me, but this completely
> broke amdgpu.
>
> Alex any idea what is going on here?
What's broken in amdgpu? There shouldn't be any ttm changes in amdgpu
for drm-next. Those all go through drm-misc.
It's not a TTM change.
The backmerge of drm-next into drm-misc-next broke amdgpu so that even
glxgears doesn't work anymore.
But each individual merge head still works fine as far as I can say.
Any idea how to track that down?
The backmerge brought in
Fixes: 16e6eea29d7b ("Merge tag 'amd-drm-fixes-5.9-2020-08-07' ...)
which has quite a few commit. Maybe it's in one of them.
Nope, I have just double checked that I can revert either parent of the merge
and the problem disappears.
I somehow need to figure out how to cleanly revert all patches in one branch
one by one and then do a reverse bisect. Oh, sometimes I love my job :(
If anybody has a good idea how to do this please speak up.
Thanks,
Christian.
Best regards
Thomas
Christian.
Alex
>
> Regards,
> Christian.
>
> Am 12.08.20 um 21:10 schrieb Thomas Zimmermann:
> > Hi Christian and Ben,
> >
> > I backmerged drm-next into drm-misc-next and had a conflict between ttm
> > and nouveau. struct ttm_mem_res got renamed to struct ttm_resource. I
> > updated nouveau to the new name, test-built, and pushed the result to
> > drm-misc-next. If either of you has a minute, you may want to double
> > check the merge.
> >
> > Best regards
> > Thomas
> >
>
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>
>
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfxdata=02%7C01%7Cchristian.koenig%40amd.com%7Ca1aefc1ee22a4e733df908d8406a395c%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637330172275088649sdata=X2ZJUETwoq884Xtg66sDudjXB%2F3s%2BgRglnh33gpU4Hc%3Dreserved=0<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx=02%7C01%7CAlexander.Deucher%40amd.com%7Cd4023becdee744c639ae08d843885b15%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637333600213437608=pbqERBZPwTFVObebH8KIPIxOtDYrjMu4SIaJ%2FF13cXk%3D=0>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>
https://lists.freedesktop.org/mailman/listinfo/amd-gfx<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx=02%7C01%7CAlexander.Deucher%40amd.com%7Cd4023becdee744c639ae08d843885b15%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637333600213447604=r8BFPhKT1KzcpVZQIy0Im4%2Bjb9S75c7doKvtH2FGjA8%3D=0>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] Revert "drm/amdgpu: disable gfxoff for navy_flounder"
[AMD Public Use] Acked-by: Alex Deucher From: amd-gfx on behalf of Jiansong Chen Sent: Monday, August 17, 2020 10:45 AM To: amd-gfx@lists.freedesktop.org Cc: Zhou1, Tao ; Feng, Kenneth ; Chen, Jiansong (Simon) Subject: [PATCH] Revert "drm/amdgpu: disable gfxoff for navy_flounder" This reverts commit 6a72ad7e387c6fec821c230fda3460f79fc0f877. Newly released sdma fw (51.52) provides a fix for the issue. --- drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c index e87d43537013..e527be22a3d5 100644 --- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c @@ -3610,9 +3610,6 @@ static void gfx_v10_0_check_gfxoff_flag(struct amdgpu_device *adev) if (!gfx_v10_0_navi10_gfxoff_should_enable(adev)) adev->pm.pp_feature &= ~PP_GFXOFF_MASK; break; - case CHIP_NAVY_FLOUNDER: - adev->pm.pp_feature &= ~PP_GFXOFF_MASK; - break; default: break; } -- 2.25.1 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfxdata=02%7C01%7Calexander.deucher%40amd.com%7Cfe56ae8b28a642d0860008d842bc43e4%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637332723663638132sdata=xMP4WmjGoryNjXtsOAaOe%2FmzdL%2FWe1BEvOJ0DOAUAWo%3Dreserved=0 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 1/5] drm/amd/pm: disable/enable deep sleep features on UMD pstate enter/exit
[AMD Public Use]
You can probably just squash patches 2-5 into one patch. Either way, series is:
Reviewed-by: Alex Deucher
From: Quan, Evan
Sent: Monday, August 17, 2020 4:29 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Quan, Evan
Subject: [PATCH 1/5] drm/amd/pm: disable/enable deep sleep features on UMD
pstate enter/exit
Add deep sleep disablement/enablement on UMD pstate entering/exiting.
Change-Id: I4fbc02bb4a390ab82293a5ff9c91f2a8beb0a3c9
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/pm/inc/amdgpu_smu.h | 1 +
drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 2 ++
drivers/gpu/drm/amd/pm/swsmu/smu_internal.h | 1 +
3 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/amd/pm/inc/amdgpu_smu.h
b/drivers/gpu/drm/amd/pm/inc/amdgpu_smu.h
index 7cc707ec21c3..4c5c041af4ee 100644
--- a/drivers/gpu/drm/amd/pm/inc/amdgpu_smu.h
+++ b/drivers/gpu/drm/amd/pm/inc/amdgpu_smu.h
@@ -597,6 +597,7 @@ struct pptable_funcs {
ssize_t (*get_gpu_metrics)(struct smu_context *smu, void **table);
int (*enable_mgpu_fan_boost)(struct smu_context *smu);
int (*gfx_ulv_control)(struct smu_context *smu, bool enablement);
+ int (*deep_sleep_control)(struct smu_context *smu, bool enablement);
};
typedef enum {
diff --git a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
index 221b5c923ce1..8eb5b92903cd 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
@@ -1441,6 +1441,7 @@ static int smu_enable_umd_pstate(void *handle,
AMD_IP_BLOCK_TYPE_GFX,
AMD_CG_STATE_UNGATE);
smu_gfx_ulv_control(smu, false);
+ smu_deep_sleep_control(smu, false);
}
} else {
/* exit umd pstate, restore level, enable gfx cg*/
@@ -1448,6 +1449,7 @@ static int smu_enable_umd_pstate(void *handle,
if (*level == AMD_DPM_FORCED_LEVEL_PROFILE_EXIT)
*level = smu_dpm_ctx->saved_dpm_level;
smu_dpm_ctx->enable_umd_pstate = false;
+ smu_deep_sleep_control(smu, true);
smu_gfx_ulv_control(smu, true);
amdgpu_device_ip_set_clockgating_state(smu->adev,
AMD_IP_BLOCK_TYPE_GFX,
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu_internal.h
b/drivers/gpu/drm/amd/pm/swsmu/smu_internal.h
index 2fe29c6a00ce..c88f8fab1bae 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu_internal.h
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu_internal.h
@@ -93,6 +93,7 @@
#define smu_get_pp_feature_mask(smu, buf)
smu_ppt_funcs(get_pp_feature_mask, 0, smu, buf)
#define smu_set_pp_feature_mask(smu, new_mask)
smu_ppt_funcs(set_pp_feature_mask, 0, smu, new_mask)
#define smu_gfx_ulv_control(smu, enablement)
smu_ppt_funcs(gfx_ulv_control, 0, smu, enablement)
+#define smu_deep_sleep_control(smu, enablement)
smu_ppt_funcs(deep_sleep_control, 0, smu, enablement)
#endif
#endif
--
2.28.0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 1/5] drm/amd/pm: disable/enable gfx ulv on UMD pstate enter/exit
[AMD Official Use Only - Internal Distribution Only]
You can probably just squash patches 2-5 into one patch. Either way, series is:
Reviewed-by: Alex Deucher
From: Quan, Evan
Sent: Monday, August 17, 2020 3:49 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Quan, Evan
Subject: [PATCH 1/5] drm/amd/pm: disable/enable gfx ulv on UMD pstate enter/exit
Add gfx ulv disablement/enablement on UMD pstate entering/exiting.
Change-Id: Ieb38fdb5975b563f24c0b172fedd01acf99afb10
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/pm/inc/amdgpu_smu.h | 1 +
drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 2 ++
drivers/gpu/drm/amd/pm/swsmu/smu_internal.h | 1 +
3 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/amd/pm/inc/amdgpu_smu.h
b/drivers/gpu/drm/amd/pm/inc/amdgpu_smu.h
index bbe4a343e9f1..7cc707ec21c3 100644
--- a/drivers/gpu/drm/amd/pm/inc/amdgpu_smu.h
+++ b/drivers/gpu/drm/amd/pm/inc/amdgpu_smu.h
@@ -596,6 +596,7 @@ struct pptable_funcs {
int (*set_pp_feature_mask)(struct smu_context *smu, uint64_t new_mask);
ssize_t (*get_gpu_metrics)(struct smu_context *smu, void **table);
int (*enable_mgpu_fan_boost)(struct smu_context *smu);
+ int (*gfx_ulv_control)(struct smu_context *smu, bool enablement);
};
typedef enum {
diff --git a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
index 7d17c4f1b489..221b5c923ce1 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
@@ -1440,6 +1440,7 @@ static int smu_enable_umd_pstate(void *handle,
amdgpu_device_ip_set_clockgating_state(smu->adev,
AMD_IP_BLOCK_TYPE_GFX,
AMD_CG_STATE_UNGATE);
+ smu_gfx_ulv_control(smu, false);
}
} else {
/* exit umd pstate, restore level, enable gfx cg*/
@@ -1447,6 +1448,7 @@ static int smu_enable_umd_pstate(void *handle,
if (*level == AMD_DPM_FORCED_LEVEL_PROFILE_EXIT)
*level = smu_dpm_ctx->saved_dpm_level;
smu_dpm_ctx->enable_umd_pstate = false;
+ smu_gfx_ulv_control(smu, true);
amdgpu_device_ip_set_clockgating_state(smu->adev,
AMD_IP_BLOCK_TYPE_GFX,
AMD_CG_STATE_GATE);
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu_internal.h
b/drivers/gpu/drm/amd/pm/swsmu/smu_internal.h
index 264073d4e263..2fe29c6a00ce 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu_internal.h
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu_internal.h
@@ -92,6 +92,7 @@
#define smu_get_asic_power_limits(smu)
smu_ppt_funcs(get_power_limit, 0, smu)
#define smu_get_pp_feature_mask(smu, buf)
smu_ppt_funcs(get_pp_feature_mask, 0, smu, buf)
#define smu_set_pp_feature_mask(smu, new_mask)
smu_ppt_funcs(set_pp_feature_mask, 0, smu, new_mask)
+#define smu_gfx_ulv_control(smu, enablement)
smu_ppt_funcs(gfx_ulv_control, 0, smu, enablement)
#endif
#endif
--
2.28.0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu: Fix incorrect return value in sysfs for pp_od_clk_voltage
[AMD Public Use]
No need to apologize, it was a good catch. Something to double check in the
future if something similar ends up getting applied again.
Thanks!
Alex
From: amd-gfx on behalf of Matt Coffin
Sent: Friday, August 14, 2020 3:13 PM
To: amd-gfx@lists.freedesktop.org
Cc: Quan, Evan ; Koenig, Christian
; Li, Dennis
Subject: Re: [PATCH] drm/amdgpu: Fix incorrect return value in sysfs for
pp_od_clk_voltage
Hi all,
As of 026acaeac2d205f22c0f682cc1c7b1a85b9ccd00 ("drm/amdgpu: revert "fix
system hang issue during GPU reset""), this patch is no longer needed,
and won't apply, because the badly-behaving code was removed; I'll
withdraw this patch for now.
Sorry to those who wasted their time reviewing.
Cheers,
Matt
On 8/13/20 7:15 PM, Matt Coffin wrote:
> The changes in edad8312cbbf9a33c86873fc4093664f150dd5c1 introduced an
> issue with the sysfs interface for pp_od_clk_voltage. It overwrites the
> return value to 0 when it calls another function, then returns 0. The
> intended behavior is that a positive return value indicates the number
> of bytes from the buffer that you processed in that call.
>
> With the 0 return value, clients would submit the same value to be
> written over and over again, resulting in an infinite loop.
>
> This is resolved by returning the count of bytes read (in this case the
> whole message), when the desired return is 0 (success).
>
> Fixes: edad8312cbbf ("drm/amdgpu: fix system hang issue during GPU")
> Bug:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fdrm%2Famd%2F-%2Fissues%2F1245data=02%7C01%7Calexander.deucher%40amd.com%7C3fb1fd9f95ad441a88a208d840862e80%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637330292979204288sdata=iABLxfzQVQa5zBK6a0JozvRYl%2Fg5eTFnfOS86r0g9rU%3Dreserved=0
> Signed-off-by: Matt Coffin
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> index 1705e328c6fc..f00c7ed361d4 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> @@ -937,7 +937,11 @@ static ssize_t amdgpu_set_pp_od_clk_voltage(struct
> device *dev,
>
> pro_end:
>up_read(>reset_sem);
> - return ret;
> + if (ret) {
> + return ret;
> + } else {
> + return count;
> + }
> }
>
> static ssize_t amdgpu_get_pp_od_clk_voltage(struct device *dev,
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfxdata=02%7C01%7Calexander.deucher%40amd.com%7C3fb1fd9f95ad441a88a208d840862e80%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637330292979204288sdata=GLWlbhgo0grFjcOh5ZAJWhXGxSm6Ufw8eDFDHZf95Uk%3Dreserved=0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu/jpeg: remove redundant check when it returns
[AMD Public Use] Reviewed-by: Alex Deucher From: amd-gfx on behalf of Leo Liu Sent: Thursday, August 13, 2020 3:40 PM To: amd-gfx@lists.freedesktop.org Cc: Liu, Leo Subject: [PATCH] drm/amdgpu/jpeg: remove redundant check when it returns Fix warning from kernel test robot Signed-off-by: Leo Liu --- drivers/gpu/drm/amd/amdgpu/jpeg_v3_0.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/jpeg_v3_0.c b/drivers/gpu/drm/amd/amdgpu/jpeg_v3_0.c index c41e5590a701..f4ba423af051 100644 --- a/drivers/gpu/drm/amd/amdgpu/jpeg_v3_0.c +++ b/drivers/gpu/drm/amd/amdgpu/jpeg_v3_0.c @@ -465,8 +465,6 @@ static int jpeg_v3_0_wait_for_idle(void *handle) ret = SOC15_WAIT_ON_RREG(JPEG, 0, mmUVD_JRBC_STATUS, UVD_JRBC_STATUS__RB_JOB_DONE_MASK, UVD_JRBC_STATUS__RB_JOB_DONE_MASK); - if (ret) - return ret; return ret; } -- 2.25.1 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfxdata=02%7C01%7Calexander.deucher%40amd.com%7C3024a7a58bf24bc3731b08d83fc0df59%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637329444922074471sdata=VqEE7z0JlPSNE0nH3HFISbRGPF7tC0uNgBB3yJnSSHo%3Dreserved=0 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu: load ta firmware for navy_flounder
[AMD Public Use]
Reviewed-by: Alex Deucher
From: Bhawanpreet Lakha
Sent: Wednesday, August 12, 2020 4:17 PM
To: Kazlauskas, Nicholas ; Deucher, Alexander
; amd-gfx@lists.freedesktop.org
Cc: Clements, John ; Lakha, Bhawanpreet
Subject: [PATCH] drm/amdgpu: load ta firmware for navy_flounder
call psp_int_ta_microcode() to parse the ta firmware.
Signed-off-by: Bhawanpreet Lakha
---
drivers/gpu/drm/amd/amdgpu/psp_v11_0.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
b/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
index d488d250805d..6c5d9612abcb 100644
--- a/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
@@ -58,7 +58,7 @@ MODULE_FIRMWARE("amdgpu/arcturus_ta.bin");
MODULE_FIRMWARE("amdgpu/sienna_cichlid_sos.bin");
MODULE_FIRMWARE("amdgpu/sienna_cichlid_ta.bin");
MODULE_FIRMWARE("amdgpu/navy_flounder_sos.bin");
-MODULE_FIRMWARE("amdgpu/navy_flounder_asd.bin");
+MODULE_FIRMWARE("amdgpu/navy_flounder_ta.bin");
/* address block */
#define smnMP1_FIRMWARE_FLAGS 0x3010024
@@ -179,12 +179,11 @@ static int psp_v11_0_init_microcode(struct psp_context
*psp)
}
break;
case CHIP_SIENNA_CICHLID:
+ case CHIP_NAVY_FLOUNDER:
err = psp_init_ta_microcode(>psp, chip_name);
if (err)
return err;
break;
- case CHIP_NAVY_FLOUNDER:
- break;
default:
BUG();
}
--
2.17.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdkfd: fix the wrong sdma instance query for renoir
[AMD Public Use]
Reviewed-by: Alex Deucher
From: amd-gfx on behalf of Huang Rui
Sent: Tuesday, August 11, 2020 2:27 AM
To: amd-gfx@lists.freedesktop.org
Cc: Kuehling, Felix ; Huang, Ray
Subject: [PATCH] drm/amdkfd: fix the wrong sdma instance query for renoir
Renoir only has one sdma instance, it will get failed once query the
sdma1 registers. So use switch-case instead of static register array.
Signed-off-by: Huang Rui
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c | 31 +--
1 file changed, 22 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c
index 032d3c866280..23ccfe0ad5d4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c
@@ -197,19 +197,32 @@ static uint32_t get_sdma_rlc_reg_offset(struct
amdgpu_device *adev,
unsigned int engine_id,
unsigned int queue_id)
{
- uint32_t sdma_engine_reg_base[2] = {
- SOC15_REG_OFFSET(SDMA0, 0,
-mmSDMA0_RLC0_RB_CNTL) - mmSDMA0_RLC0_RB_CNTL,
- SOC15_REG_OFFSET(SDMA1, 0,
-mmSDMA1_RLC0_RB_CNTL) - mmSDMA1_RLC0_RB_CNTL
- };
- uint32_t retval = sdma_engine_reg_base[engine_id]
+ uint32_t sdma_engine_reg_base = 0;
+ uint32_t sdma_rlc_reg_offset;
+
+ switch (engine_id) {
+ default:
+ dev_warn(adev->dev,
+"Invalid sdma engine id (%d), using engine id 0\n",
+engine_id);
+ /* fall through */
+ case 0:
+ sdma_engine_reg_base = SOC15_REG_OFFSET(SDMA0, 0,
+ mmSDMA0_RLC0_RB_CNTL) - mmSDMA0_RLC0_RB_CNTL;
+ break;
+ case 1:
+ sdma_engine_reg_base = SOC15_REG_OFFSET(SDMA1, 0,
+ mmSDMA1_RLC0_RB_CNTL) - mmSDMA0_RLC0_RB_CNTL;
+ break;
+ }
+
+ sdma_rlc_reg_offset = sdma_engine_reg_base
+ queue_id * (mmSDMA0_RLC1_RB_CNTL - mmSDMA0_RLC0_RB_CNTL);
pr_debug("RLC register offset for SDMA%d RLC%d: 0x%x\n", engine_id,
- queue_id, retval);
+queue_id, sdma_rlc_reg_offset);
- return retval;
+ return sdma_rlc_reg_offset;
}
static inline struct v9_mqd *get_mqd(void *mqd)
--
2.25.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfxdata=02%7C01%7Calexander.deucher%40amd.com%7C575d3b20ab90469e7a5208d83dbfa612%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637327240654534583sdata=u%2By9MwOEH7bGIQbajnefKann2HyJ%2FWRG6I91FBgVakM%3Dreserved=0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amd/powerplay: bump NAVI12 driver if version
[AMD Public Use] Acked-by: Alex Deucher From: Quan, Evan Sent: Monday, August 10, 2020 11:37 PM To: amd-gfx@lists.freedesktop.org Cc: Deucher, Alexander ; Quan, Evan Subject: [PATCH] drm/amd/powerplay: bump NAVI12 driver if version To fit the latest SMU firmware. Change-Id: Ic9d02de54d20b6b90d18bac8b3fbb356d8fdf3ad Signed-off-by: Evan Quan --- drivers/gpu/drm/amd/powerplay/inc/smu_v11_0.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/powerplay/inc/smu_v11_0.h b/drivers/gpu/drm/amd/powerplay/inc/smu_v11_0.h index ee1506beb0ea..65363d56e3cc 100644 --- a/drivers/gpu/drm/amd/powerplay/inc/smu_v11_0.h +++ b/drivers/gpu/drm/amd/powerplay/inc/smu_v11_0.h @@ -28,7 +28,7 @@ #define SMU11_DRIVER_IF_VERSION_INV 0x #define SMU11_DRIVER_IF_VERSION_ARCT 0x17 #define SMU11_DRIVER_IF_VERSION_NV10 0x36 -#define SMU11_DRIVER_IF_VERSION_NV12 0x33 +#define SMU11_DRIVER_IF_VERSION_NV12 0x36 #define SMU11_DRIVER_IF_VERSION_NV14 0x36 #define SMU11_DRIVER_IF_VERSION_Sienna_Cichlid 0x35 #define SMU11_DRIVER_IF_VERSION_Navy_Flounder 0x3 -- 2.28.0 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 1/2] drm/amd/powerplay: update the metrics table cache interval as 1ms
[AMD Public Use]
Series is:
Reviewed-by: Alex Deucher
From: Quan, Evan
Sent: Monday, August 10, 2020 11:35 PM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Quan, Evan
Subject: [PATCH 1/2] drm/amd/powerplay: update the metrics table cache interval
as 1ms
To make the setting same as Arcturus/Navi1x/Sienna_Cichlid.
Change-Id: I7ea721bf5872023f1ab39c3827fb9c6fd05877cc
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c | 2 +-
drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c | 2 +-
drivers/gpu/drm/amd/powerplay/renoir_ppt.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c
index c70c30175801..f0680dd58508 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c
@@ -1272,7 +1272,7 @@ static int vega12_get_metrics_table(struct pp_hwmgr
*hwmgr,
if (bypass_cache ||
!data->metrics_time ||
- time_after(jiffies, data->metrics_time + HZ / 2)) {
+ time_after(jiffies, data->metrics_time + msecs_to_jiffies(1))) {
ret = smum_smc_table_manager(hwmgr,
(uint8_t *)(>metrics_table),
TABLE_SMU_METRICS,
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c
index c9f402edc0d6..da84012b7fd5 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c
@@ -2082,7 +2082,7 @@ static int vega20_get_metrics_table(struct pp_hwmgr
*hwmgr,
if (bypass_cache ||
!data->metrics_time ||
- time_after(jiffies, data->metrics_time + HZ / 2)) {
+ time_after(jiffies, data->metrics_time + msecs_to_jiffies(1))) {
ret = smum_smc_table_manager(hwmgr,
(uint8_t *)(>metrics_table),
TABLE_SMU_METRICS,
diff --git a/drivers/gpu/drm/amd/powerplay/renoir_ppt.c
b/drivers/gpu/drm/amd/powerplay/renoir_ppt.c
index 8a8e6033f71f..c50c4547fea9 100644
--- a/drivers/gpu/drm/amd/powerplay/renoir_ppt.c
+++ b/drivers/gpu/drm/amd/powerplay/renoir_ppt.c
@@ -139,7 +139,7 @@ static int renoir_get_metrics_table(struct smu_context *smu,
if (bypass_cache ||
!smu_table->metrics_time ||
- time_after(jiffies, smu_table->metrics_time +
msecs_to_jiffies(100))) {
+ time_after(jiffies, smu_table->metrics_time + msecs_to_jiffies(1)))
{
ret = smu_cmn_update_table(smu, SMU_TABLE_SMU_METRICS, 0,
(void *)smu_table->metrics_table, false);
if (ret) {
--
2.28.0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amd/powerplay: correct Vega20 cached smu feature state
[AMD Official Use Only - Internal Distribution Only]
Acked-by: Alex Deucher
From: Quan, Evan
Sent: Friday, August 7, 2020 5:30 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Kuehling, Felix
; Quan, Evan
Subject: [PATCH] drm/amd/powerplay: correct Vega20 cached smu feature state
Correct the cached smu feature state on pp_features sysfs
setting.
Change-Id: Icc4c3ce764876a0ffdc86ad4c8a8b9c9f0ed0e97
Signed-off-by: Evan Quan
---
.../drm/amd/powerplay/hwmgr/vega20_hwmgr.c| 38 +--
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c
index 90c78f127f7e..acc926c20c55 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c
@@ -984,10 +984,7 @@ static int vega20_disable_all_smu_features(struct pp_hwmgr
*hwmgr)
{
struct vega20_hwmgr *data =
(struct vega20_hwmgr *)(hwmgr->backend);
- uint64_t features_enabled;
- int i;
- bool enabled;
- int ret = 0;
+ int i, ret = 0;
PP_ASSERT_WITH_CODE((ret = smum_send_msg_to_smc(hwmgr,
PPSMC_MSG_DisableAllSmuFeatures,
@@ -995,17 +992,8 @@ static int vega20_disable_all_smu_features(struct pp_hwmgr
*hwmgr)
"[DisableAllSMUFeatures] Failed to disable all smu
features!",
return ret);
- ret = vega20_get_enabled_smc_features(hwmgr, _enabled);
- PP_ASSERT_WITH_CODE(!ret,
- "[DisableAllSMUFeatures] Failed to get enabled smc
features!",
- return ret);
-
- for (i = 0; i < GNLD_FEATURES_MAX; i++) {
- enabled = (features_enabled &
data->smu_features[i].smu_feature_bitmap) ?
- true : false;
- data->smu_features[i].enabled = enabled;
- data->smu_features[i].supported = enabled;
- }
+ for (i = 0; i < GNLD_FEATURES_MAX; i++)
+ data->smu_features[i].enabled = 0;
return 0;
}
@@ -3242,10 +3230,11 @@ static int vega20_get_ppfeature_status(struct pp_hwmgr
*hwmgr, char *buf)
static int vega20_set_ppfeature_status(struct pp_hwmgr *hwmgr, uint64_t
new_ppfeature_masks)
{
- uint64_t features_enabled;
- uint64_t features_to_enable;
- uint64_t features_to_disable;
- int ret = 0;
+ struct vega20_hwmgr *data =
+ (struct vega20_hwmgr *)(hwmgr->backend);
+ uint64_t features_enabled, features_to_enable, features_to_disable;
+ int i, ret = 0;
+ bool enabled;
if (new_ppfeature_masks >= (1ULL << GNLD_FEATURES_MAX))
return -EINVAL;
@@ -3274,6 +3263,17 @@ static int vega20_set_ppfeature_status(struct pp_hwmgr
*hwmgr, uint64_t new_ppfe
return ret;
}
+ /* Update the cached feature enablement state */
+ ret = vega20_get_enabled_smc_features(hwmgr, _enabled);
+ if (ret)
+ return ret;
+
+ for (i = 0; i < GNLD_FEATURES_MAX; i++) {
+ enabled = (features_enabled &
data->smu_features[i].smu_feature_bitmap) ?
+ true : false;
+ data->smu_features[i].enabled = enabled;
+ }
+
return 0;
}
--
2.28.0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amd/powerplay: correct UVD/VCE PG state on custom pptable uploading
[AMD Official Use Only - Internal Distribution Only] Acked-by: Alex Deucher From: Quan, Evan Sent: Friday, August 7, 2020 5:31 AM To: amd-gfx@lists.freedesktop.org Cc: Deucher, Alexander ; Quan, Evan Subject: [PATCH] drm/amd/powerplay: correct UVD/VCE PG state on custom pptable uploading The UVD/VCE PG state is managed by UVD and VCE IP. It's error-prone to assume the bootup state in SMU based on the dpm status. Change-Id: Ib88298ab9812d7d242592bcd55eea140bef6696a Signed-off-by: Evan Quan --- drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c | 6 -- 1 file changed, 6 deletions(-) diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c b/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c index acc926c20c55..da84012b7fd5 100644 --- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c @@ -1645,12 +1645,6 @@ static void vega20_init_powergate_state(struct pp_hwmgr *hwmgr) data->uvd_power_gated = true; data->vce_power_gated = true; - - if (data->smu_features[GNLD_DPM_UVD].enabled) - data->uvd_power_gated = false; - - if (data->smu_features[GNLD_DPM_VCE].enabled) - data->vce_power_gated = false; } static int vega20_enable_dpm_tasks(struct pp_hwmgr *hwmgr) -- 2.28.0 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 1/1] drm/ttm: fix offset in VMAs with a pg_offs in ttm_bo_vm_access
[AMD Public Use]
Christian, Can you cc stable when you apply it to drm-misc?
Alex
From: Kuehling, Felix
Sent: Wednesday, July 29, 2020 10:15 AM
To: Koenig, Christian ;
dri-de...@lists.freedesktop.org ;
amd-gfx@lists.freedesktop.org ; Deucher,
Alexander
Cc: Morichetti, Laurent
Subject: Re: [PATCH 1/1] drm/ttm: fix offset in VMAs with a pg_offs in
ttm_bo_vm_access
Am 2020-07-29 um 4:08 a.m. schrieb Christian König:
> Am 28.07.20 um 20:27 schrieb Felix Kuehling:
>> VMAs with a pg_offs that's offset from the start of the vma_node need
>> to adjust the offset within the BO accordingly. This matches the
>> offset calculation in ttm_bo_vm_fault_reserved.
>>
>> Signed-off-by: Felix Kuehling
>> Tested-by: Laurent Morichetti
>
> Reviewed-by: Christian König
>
> Going to pick that up for inclusion in drm-misc-next.
Thanks. I'll submit it to amd-staging-drm-next so it makes its way into
our DKMS branch quickly.
Alex, would you push this to drm-fixes?
Regards,
Felix
>
>> ---
>> drivers/gpu/drm/ttm/ttm_bo_vm.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c
>> b/drivers/gpu/drm/ttm/ttm_bo_vm.c
>> index 389128b8c4dd..60b41447bec8 100644
>> --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
>> +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
>> @@ -405,8 +405,10 @@ static int ttm_bo_vm_access_kmap(struct
>> ttm_buffer_object *bo,
>> int ttm_bo_vm_access(struct vm_area_struct *vma, unsigned long addr,
>>void *buf, int len, int write)
>> {
>> -unsigned long offset = (addr) - vma->vm_start;
>> struct ttm_buffer_object *bo = vma->vm_private_data;
>> +unsigned long offset = (addr) - vma->vm_start +
>> +((vma->vm_pgoff - drm_vma_node_start(>base.vma_node))
>> + << PAGE_SHIFT);
>> int ret;
>> if (len < 1 || (offset + len) >> PAGE_SHIFT > bo->num_pages)
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu: reconfigure spm golden settings on Navi1x after GFXOFF exit(v2)
Are any of those situations really time sensitive? Otherwise, I think we'll
end up having to patch this in everywhere we want SPM to be consistent.
Alex
From: Yin, Tianci (Rico)
Sent: Tuesday, July 28, 2020 10:26 PM
To: Deucher, Alexander ;
amd-gfx@lists.freedesktop.org
Cc: Tuikov, Luben ; Zhang, Hawking
; Xu, Feifei ; Hesik, Christopher
; Swamy, Manjunatha ;
Quan, Evan ; Chen, Guchun ; Feng,
Kenneth
Subject: Re: [PATCH] drm/amdgpu: reconfigure spm golden settings on Navi1x
after GFXOFF exit(v2)
[AMD Public Use]
Hi Alex,
amdgpu_gfx_off_ctrl() invoked by a few other functions, like
amdgpu_info_ioctl() ,
putting the code into amdgpu_gfx_off_ctrl() will cost more meaningless time on
SPM golden reconfiguration.
amdgpu_gfx_off_ctrl(adev, false);
amdgpu_asic_read_register(adev, se_num, sh_num, info->read_mmr_reg.dword_offset
+ i, [i]);
amdgpu_gfx_off_ctrl(adev, true);
In most cases, we don't care about the SPM, so I think smu_enable_umd_pstate is
a better place.
Thanks very much!
Rico
From: Deucher, Alexander
Sent: Tuesday, July 28, 2020 22:16
To: Yin, Tianci (Rico) ; amd-gfx@lists.freedesktop.org
Cc: Tuikov, Luben ; Zhang, Hawking
; Xu, Feifei ; Hesik, Christopher
; Swamy, Manjunatha ;
Quan, Evan ; Chen, Guchun ; Feng,
Kenneth
Subject: Re: [PATCH] drm/amdgpu: reconfigure spm golden settings on Navi1x
after GFXOFF exit(v2)
[AMD Public Use]
Would it be better to put this code into amdgpu_gfx_off_ctrl()? Then we'll
handle this in all cases where we disable gfx off.
Alex
From: Tianci Yin
Sent: Tuesday, July 28, 2020 3:04 AM
To: amd-gfx@lists.freedesktop.org
Cc: Tuikov, Luben ; Deucher, Alexander
; Zhang, Hawking ; Xu, Feifei
; Hesik, Christopher ; Swamy,
Manjunatha ; Quan, Evan ; Chen,
Guchun ; Feng, Kenneth ; Yin, Tianci
(Rico)
Subject: [PATCH] drm/amdgpu: reconfigure spm golden settings on Navi1x after
GFXOFF exit(v2)
From: "Tianci.Yin"
On Navi1x, the SPM golden settings will be lost after GFXOFF enter/exit,
reconfigure the golden settings after GFXOFF exit.
Change-Id: I9358ba9c65f241c36f8a35916170b19535148ee9
Reviewed-by: Feifei Xu
Signed-off-by: Tianci.Yin
---
drivers/gpu/drm/amd/powerplay/amdgpu_smu.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c
b/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c
index 55463e7a11e2..41487123c207 100644
--- a/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c
+++ b/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c
@@ -1309,6 +1309,7 @@ static int smu_enable_umd_pstate(void *handle,
struct smu_context *smu = (struct smu_context*)(handle);
struct smu_dpm_context *smu_dpm_ctx = &(smu->smu_dpm);
+ struct amdgpu_device *adev = smu->adev;
if (!smu->is_apu && !smu_dpm_ctx->dpm_context)
return -EINVAL;
@@ -1318,12 +1319,22 @@ static int smu_enable_umd_pstate(void *handle,
if (*level & profile_mode_mask) {
smu_dpm_ctx->saved_dpm_level = smu_dpm_ctx->dpm_level;
smu_dpm_ctx->enable_umd_pstate = true;
- amdgpu_device_ip_set_powergating_state(smu->adev,
+ amdgpu_device_ip_set_powergating_state(adev,
AMD_IP_BLOCK_TYPE_GFX,
AMD_PG_STATE_UNGATE);
- amdgpu_device_ip_set_clockgating_state(smu->adev,
+ amdgpu_device_ip_set_clockgating_state(adev,
AMD_IP_BLOCK_TYPE_GFX,
AMD_CG_STATE_UNGATE);
+
+ if (adev->asic_type >= CHIP_NAVI10 &&
+ adev->asic_type <= CHIP_NAVI12 &&
+ (adev->pm.pp_feature & PP_GFXOFF_MASK)) {
+ if (adev->gfx.funcs->init_spm_golden) {
+ dev_dbg(adev->dev,"GFXOFF exited,
re-init SPM golden settings\n");
+ amdgpu_gfx_init_spm_golden(adev);
+ } else
+ dev_warn(adev->dev,"Callback
init_spm_golden is NULL\n");
+ }
}
} else {
/* exit umd pstate, restore level, enable gfx cg*/
@@ -1331,10 +1342,10 @@ static int smu_enable_umd_pstate(void *handle,
if (*level == AMD_DPM_FORCED_LEVEL_PROFILE_EXIT)
*level = smu_dpm_ctx->saved_dpm_level;
smu_dpm_ctx->enable_umd_pstate = false;
-
Re: [PATCH] drm/amdgpu: reconfigure spm golden settings on Navi1x after GFXOFF exit(v2)
[AMD Public Use]
Would it be better to put this code into amdgpu_gfx_off_ctrl()? Then we'll
handle this in all cases where we disable gfx off.
Alex
From: Tianci Yin
Sent: Tuesday, July 28, 2020 3:04 AM
To: amd-gfx@lists.freedesktop.org
Cc: Tuikov, Luben ; Deucher, Alexander
; Zhang, Hawking ; Xu, Feifei
; Hesik, Christopher ; Swamy,
Manjunatha ; Quan, Evan ; Chen,
Guchun ; Feng, Kenneth ; Yin, Tianci
(Rico)
Subject: [PATCH] drm/amdgpu: reconfigure spm golden settings on Navi1x after
GFXOFF exit(v2)
From: "Tianci.Yin"
On Navi1x, the SPM golden settings will be lost after GFXOFF enter/exit,
reconfigure the golden settings after GFXOFF exit.
Change-Id: I9358ba9c65f241c36f8a35916170b19535148ee9
Reviewed-by: Feifei Xu
Signed-off-by: Tianci.Yin
---
drivers/gpu/drm/amd/powerplay/amdgpu_smu.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c
b/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c
index 55463e7a11e2..41487123c207 100644
--- a/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c
+++ b/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c
@@ -1309,6 +1309,7 @@ static int smu_enable_umd_pstate(void *handle,
struct smu_context *smu = (struct smu_context*)(handle);
struct smu_dpm_context *smu_dpm_ctx = &(smu->smu_dpm);
+ struct amdgpu_device *adev = smu->adev;
if (!smu->is_apu && !smu_dpm_ctx->dpm_context)
return -EINVAL;
@@ -1318,12 +1319,22 @@ static int smu_enable_umd_pstate(void *handle,
if (*level & profile_mode_mask) {
smu_dpm_ctx->saved_dpm_level = smu_dpm_ctx->dpm_level;
smu_dpm_ctx->enable_umd_pstate = true;
- amdgpu_device_ip_set_powergating_state(smu->adev,
+ amdgpu_device_ip_set_powergating_state(adev,
AMD_IP_BLOCK_TYPE_GFX,
AMD_PG_STATE_UNGATE);
- amdgpu_device_ip_set_clockgating_state(smu->adev,
+ amdgpu_device_ip_set_clockgating_state(adev,
AMD_IP_BLOCK_TYPE_GFX,
AMD_CG_STATE_UNGATE);
+
+ if (adev->asic_type >= CHIP_NAVI10 &&
+ adev->asic_type <= CHIP_NAVI12 &&
+ (adev->pm.pp_feature & PP_GFXOFF_MASK)) {
+ if (adev->gfx.funcs->init_spm_golden) {
+ dev_dbg(adev->dev,"GFXOFF exited,
re-init SPM golden settings\n");
+ amdgpu_gfx_init_spm_golden(adev);
+ } else
+ dev_warn(adev->dev,"Callback
init_spm_golden is NULL\n");
+ }
}
} else {
/* exit umd pstate, restore level, enable gfx cg*/
@@ -1331,10 +1342,10 @@ static int smu_enable_umd_pstate(void *handle,
if (*level == AMD_DPM_FORCED_LEVEL_PROFILE_EXIT)
*level = smu_dpm_ctx->saved_dpm_level;
smu_dpm_ctx->enable_umd_pstate = false;
- amdgpu_device_ip_set_clockgating_state(smu->adev,
+ amdgpu_device_ip_set_clockgating_state(adev,
AMD_IP_BLOCK_TYPE_GFX,
AMD_CG_STATE_GATE);
- amdgpu_device_ip_set_powergating_state(smu->adev,
+ amdgpu_device_ip_set_powergating_state(adev,
AMD_IP_BLOCK_TYPE_GFX,
AMD_PG_STATE_GATE);
}
--
2.17.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 1/2] drm amdgpu: Skip tmr load for SRIOV
[AMD Official Use Only - Internal Distribution Only]
Please fix your git setup to use your name rather than "root" as the author.
Alex
From: Liu ChengZhe
Sent: Monday, July 27, 2020 6:57 AM
To: amd-gfx@lists.freedesktop.org
Cc: Tuikov, Luben ; Koenig, Christian
; Deucher, Alexander ;
Xiao, Jack ; Zhang, Hawking ; Xu,
Feifei ; Wang, Kevin(Yang) ; Yuan,
Xiaojie ; Liu, Cheng Zhe
Subject: [PATCH 1/2] drm amdgpu: Skip tmr load for SRIOV
From: root
1. For Navi12, CHIP_SIENNA_CICHLID, skip tmr load operation;
2. Check pointer before release firmware.
Signed-off-by: root
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 40 +
1 file changed, 34 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
index a053b7af0680..a9481e112cb3 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
@@ -193,12 +193,18 @@ static int psp_sw_fini(void *handle)
struct amdgpu_device *adev = (struct amdgpu_device *)handle;
psp_memory_training_fini(>psp);
- release_firmware(adev->psp.sos_fw);
- adev->psp.sos_fw = NULL;
- release_firmware(adev->psp.asd_fw);
- adev->psp.asd_fw = NULL;
- release_firmware(adev->psp.ta_fw);
- adev->psp.ta_fw = NULL;
+ if (adev->psp.sos_fw) {
+ release_firmware(adev->psp.sos_fw);
+ adev->psp.sos_fw = NULL;
+ }
+ if (adev->psp.asd_fw) {
+ release_firmware(adev->psp.asd_fw);
+ adev->psp.asd_fw = NULL;
+ }
+ if (adev->psp.ta_fw) {
+ release_firmware(adev->psp.ta_fw);
+ adev->psp.ta_fw = NULL;
+ }
if (adev->asic_type == CHIP_NAVI10)
psp_sysfs_fini(adev);
@@ -409,11 +415,33 @@ static int psp_clear_vf_fw(struct psp_context *psp)
return ret;
}
+static bool psp_skip_tmr(struct psp_context *psp)
+{
+ bool ret = false;
+
+ switch (psp->adev->asic_type) {
+ case CHIP_NAVI12:
+ case CHIP_SIENNA_CICHLID:
+ ret = true;
+ break;
+ default:
+ return false;
+ }
+
+ return ret;
+}
+
static int psp_tmr_load(struct psp_context *psp)
{
int ret;
struct psp_gfx_cmd_resp *cmd;
+ /* for Navi12 and CHIP_SIENNA_CICHLID SRIOV, do not setup TMR
+* (already setup by host driver)
+*/
+ if (amdgpu_sriov_vf(psp->adev) && psp_skip_tmr(psp))
+ return 0;
+
cmd = kzalloc(sizeof(struct psp_gfx_cmd_resp), GFP_KERNEL);
if (!cmd)
return -ENOMEM;
--
2.25.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amd/amdgpu: Fix compiler warning in df driver
[AMD Official Use Only - Internal Distribution Only]
Reviewed-by: Alex Deucher
From: amd-gfx on behalf of Tom St Denis
Sent: Wednesday, July 22, 2020 7:40 AM
To: amd-gfx@lists.freedesktop.org
Cc: StDenis, Tom
Subject: [PATCH] drm/amd/amdgpu: Fix compiler warning in df driver
Fix this warning:
CC [M] drivers/gpu/drm/amd/amdgpu/gfxhub_v1_1.o
In file included from drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h:29,
from drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.h:26,
from drivers/gpu/drm/amd/amdgpu/amdgpu.h:43,
from drivers/gpu/drm/amd/amdgpu/df_v3_6.c:23:
drivers/gpu/drm/amd/amdgpu/df_v3_6.c: In function ‘df_v3_6_pmc_get_count’:
./include/drm/drm_print.h:487:2: warning: ‘hi_base_addr’ may be used
uninitialized in this function [-Wmaybe-uninitialized]
487 | __drm_dbg(DRM_UT_DRIVER, fmt, ##__VA_ARGS__)
| ^
drivers/gpu/drm/amd/amdgpu/df_v3_6.c:649:25: note: ‘hi_base_addr’ was declared
here
649 | uint32_t lo_base_addr, hi_base_addr, lo_val = 0, hi_val = 0;
| ^~~~
In file included from drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h:29,
from drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.h:26,
from drivers/gpu/drm/amd/amdgpu/amdgpu.h:43,
from drivers/gpu/drm/amd/amdgpu/df_v3_6.c:23:
./include/drm/drm_print.h:487:2: warning: ‘lo_base_addr’ may be used
uninitialized in this function [-Wmaybe-uninitialized]
487 | __drm_dbg(DRM_UT_DRIVER, fmt, ##__VA_ARGS__)
| ^
drivers/gpu/drm/amd/amdgpu/df_v3_6.c:649:11: note: ‘lo_base_addr’ was declared
here
649 | uint32_t lo_base_addr, hi_base_addr, lo_val = 0, hi_val = 0;
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/amd/amdgpu/df_v3_6.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/df_v3_6.c
b/drivers/gpu/drm/amd/amdgpu/df_v3_6.c
index 1ab261836983..0aa1ac1accd6 100644
--- a/drivers/gpu/drm/amd/amdgpu/df_v3_6.c
+++ b/drivers/gpu/drm/amd/amdgpu/df_v3_6.c
@@ -646,7 +646,7 @@ static void df_v3_6_pmc_get_count(struct amdgpu_device
*adev,
uint64_t config,
uint64_t *count)
{
- uint32_t lo_base_addr, hi_base_addr, lo_val = 0, hi_val = 0;
+ uint32_t lo_base_addr = 0, hi_base_addr = 0, lo_val = 0, hi_val = 0;
*count = 0;
switch (adev->asic_type) {
--
2.26.2
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfxdata=02%7C01%7Calexander.deucher%40amd.com%7C95d3961b50a743867b6c08d82e340fe9%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637310148439516686sdata=mkDp4Wqa3ZSS9T1Tr%2B0HvNhb0Il2RhD4RZ6WT%2BDXL9M%3Dreserved=0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 6/6] drm/amdgpu/sienna_cichlid: add SMU i2c support
[AMD Official Use Only - Internal Distribution Only]
I tried that at first, but the smu i2c interface structures are different per
asic.
Alex
From: Grodzovsky, Andrey
Sent: Tuesday, July 21, 2020 1:01 PM
To: Alex Deucher ; amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: Re: [PATCH 6/6] drm/amdgpu/sienna_cichlid: add SMU i2c support
Looks like same code as arcturus - should we make it common helper code and
reuse in both ?
Andrey
On 7/21/20 12:52 PM, Alex Deucher wrote:
> Enable SMU i2c bus access for sienna_cichlid asics.
>
> Signed-off-by: Alex Deucher
> ---
> .../drm/amd/powerplay/sienna_cichlid_ppt.c| 239 ++
> 1 file changed, 239 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/sienna_cichlid_ppt.c
> b/drivers/gpu/drm/amd/powerplay/sienna_cichlid_ppt.c
> index 5faef41b63a3..e1857fbb0a6f 100644
> --- a/drivers/gpu/drm/amd/powerplay/sienna_cichlid_ppt.c
> +++ b/drivers/gpu/drm/amd/powerplay/sienna_cichlid_ppt.c
> @@ -23,6 +23,7 @@
>
> #include
> #include
> +#include
> #include "amdgpu.h"
> #include "amdgpu_smu.h"
> #include "smu_internal.h"
> @@ -52,6 +53,8 @@
> #undef pr_info
> #undef pr_debug
>
> +#define to_amdgpu_device(x) (container_of(x, struct amdgpu_device,
> pm.smu_i2c))
> +
> #define FEATURE_MASK(feature) (1ULL << feature)
> #define SMC_DPM_FEATURE ( \
>FEATURE_MASK(FEATURE_DPM_PREFETCHER_BIT) | \
> @@ -455,6 +458,8 @@ static int sienna_cichlid_tables_init(struct smu_context
> *smu, struct smu_table
> PAGE_SIZE, AMDGPU_GEM_DOMAIN_VRAM);
>SMU_TABLE_INIT(tables, SMU_TABLE_SMU_METRICS, sizeof(SmuMetrics_t),
> PAGE_SIZE, AMDGPU_GEM_DOMAIN_VRAM);
> + SMU_TABLE_INIT(tables, SMU_TABLE_I2C_COMMANDS, sizeof(SwI2cRequest_t),
> +PAGE_SIZE, AMDGPU_GEM_DOMAIN_VRAM);
>SMU_TABLE_INIT(tables, SMU_TABLE_OVERDRIVE, sizeof(OverDriveTable_t),
> PAGE_SIZE, AMDGPU_GEM_DOMAIN_VRAM);
>SMU_TABLE_INIT(tables, SMU_TABLE_PMSTATUSLOG, SMU11_TOOL_SIZE,
> @@ -2487,6 +2492,238 @@ static void sienna_cichlid_dump_pptable(struct
> smu_context *smu)
>dev_info(smu->adev->dev, "MmHubPadding[7] = 0x%x\n",
> pptable->MmHubPadding[7]);
> }
>
> +static void sienna_cichlid_fill_i2c_req(SwI2cRequest_t *req, bool write,
> + uint8_t address, uint32_t numbytes,
> + uint8_t *data)
> +{
> + int i;
> +
> + BUG_ON(numbytes > MAX_SW_I2C_COMMANDS);
> +
> + req->I2CcontrollerPort = 0;
> + req->I2CSpeed = 2;
> + req->SlaveAddress = address;
> + req->NumCmds = numbytes;
> +
> + for (i = 0; i < numbytes; i++) {
> + SwI2cCmd_t *cmd = >SwI2cCmds[i];
> +
> + /* First 2 bytes are always write for lower 2b EEPROM address */
> + if (i < 2)
> + cmd->CmdConfig = CMDCONFIG_READWRITE_MASK;
> + else
> + cmd->CmdConfig = write ? CMDCONFIG_READWRITE_MASK : 0;
> +
> +
> + /* Add RESTART for read after address filled */
> + cmd->CmdConfig |= (i == 2 && !write) ? CMDCONFIG_RESTART_MASK :
> 0;
> +
> + /* Add STOP in the end */172.31.4.187
> + cmd->CmdConfig |= (i == (numbytes - 1)) ? CMDCONFIG_STOP_MASK :
> 0;
> +
> + /* Fill with data regardless if read or write to simplify code
> */
> + cmd->ReadWriteData = data[i];
> + }
> +}
> +
> +static int sienna_cichlid_i2c_read_data(struct i2c_adapter *control,
> +uint8_t address,
> +uint8_t *data,
> +uint32_t numbytes)
> +{
> + uint32_t i, ret = 0;
> + SwI2cRequest_t req;
> + struct amdgpu_device *adev = to_amdgpu_device(control);
> + struct smu_table_context *smu_table = >smu.smu_table;
> + struct smu_table *table = _table->driver_table;
> +
> + memset(, 0, sizeof(req));
> + sienna_cichlid_fill_i2c_req(, false, address, numbytes, data);
> +
> + mutex_lock(>smu.mutex);
> + /* Now read data starting with that address */
> + ret = smu_update_table(>smu, SMU_TABLE_I2C_COMMANDS, 0, ,
> + true);
> + mutex_unlock(>smu.mutex);
> +
> + if (!ret) {
> + SwI2cRequest_t *res = (SwI2cRequest_t *)table->cpu_addr;
> +
> + /* Assume SMU fills res.SwI2cCmds[i].Da
Re: [PATCH 5/6] drm/amdgpu/navi1x: add SMU i2c support
[AMD Official Use Only - Internal Distribution Only] Ignore this. Sent out the wrong version. Alex From: Alex Deucher Sent: Tuesday, July 21, 2020 12:52 PM To: amd-gfx@lists.freedesktop.org Cc: Deucher, Alexander Subject: [PATCH 5/6] drm/amdgpu/navi1x: add SMU i2c support Enable SMU i2c bus access for navi1x asics. Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/powerplay/navi10_ppt.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/amd/powerplay/navi10_ppt.c b/drivers/gpu/drm/amd/powerplay/navi10_ppt.c index ead135f39c7e..56267e6c600e 100644 --- a/drivers/gpu/drm/amd/powerplay/navi10_ppt.c +++ b/drivers/gpu/drm/amd/powerplay/navi10_ppt.c @@ -23,6 +23,7 @@ #include #include +#include #include "amdgpu.h" #include "amdgpu_smu.h" #include "smu_internal.h" @@ -52,6 +53,8 @@ #undef pr_info #undef pr_debug +#define to_amdgpu_device(x) (container_of(x, struct amdgpu_device, pm.smu_i2c)) + #define FEATURE_MASK(feature) (1ULL << feature) #define SMC_DPM_FEATURE ( \ FEATURE_MASK(FEATURE_DPM_PREFETCHER_BIT) | \ -- 2.25.4 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amd/powerplay: suppress compile error around BUG_ON
[AMD Public Use]
Acked-by: Alex Deucher
From: Quan, Evan
Sent: Wednesday, July 15, 2020 2:52 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Quan, Evan
Subject: [PATCH] drm/amd/powerplay: suppress compile error around BUG_ON
To suppress the compile error below for "ARCH=arc".
drivers/gpu/drm/amd/amdgpu/../powerplay/arcturus_ppt.c: In function
'arcturus_fill_eeprom_i2c_req':
>> arch/arc/include/asm/bug.h:22:2: error: implicit declaration of function
>> 'pr_warn'; did you mean 'pci_warn'? [-Werror=implicit-function-declaration]
22 | pr_warn("BUG: failure at %s:%d/%s()!\n", __FILE__, __LINE__,
__func__); \
| ^~~
include/asm-generic/bug.h:62:57: note: in expansion of macro 'BUG'
62 | #define BUG_ON(condition) do { if (unlikely(condition)) BUG(); }
while (0)
| ^~~
drivers/gpu/drm/amd/amdgpu/../powerplay/arcturus_ppt.c:2157:2: note: in
expansion of macro 'BUG_ON'
2157 | BUG_ON(numbytes > MAX_SW_I2C_COMMANDS);
Change-Id: I314b0d08197398a04b5439bce6546c4c68ca5dff
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/powerplay/arcturus_ppt.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/arcturus_ppt.c
b/drivers/gpu/drm/amd/powerplay/arcturus_ppt.c
index fde6a8242565..0784a97bd67b 100644
--- a/drivers/gpu/drm/amd/powerplay/arcturus_ppt.c
+++ b/drivers/gpu/drm/amd/powerplay/arcturus_ppt.c
@@ -1881,8 +1881,6 @@ static void arcturus_fill_eeprom_i2c_req(SwI2cRequest_t
*req, bool write,
{
int i;
- BUG_ON(numbytes > MAX_SW_I2C_COMMANDS);
-
req->I2CcontrollerPort = 0;
req->I2CSpeed = 2;
req->SlaveAddress = address;
@@ -1920,6 +1918,12 @@ static int arcturus_i2c_eeprom_read_data(struct
i2c_adapter *control,
struct smu_table_context *smu_table = >smu.smu_table;
struct smu_table *table = _table->driver_table;
+ if (numbytes > MAX_SW_I2C_COMMANDS) {
+ dev_err(adev->dev, "numbytes requested %d is over max allowed
%d\n",
+ numbytes, MAX_SW_I2C_COMMANDS);
+ return -EINVAL;
+ }
+
memset(, 0, sizeof(req));
arcturus_fill_eeprom_i2c_req(, false, address, numbytes, data);
@@ -1956,6 +1960,12 @@ static int arcturus_i2c_eeprom_write_data(struct
i2c_adapter *control,
SwI2cRequest_t req;
struct amdgpu_device *adev = to_amdgpu_device(control);
+ if (numbytes > MAX_SW_I2C_COMMANDS) {
+ dev_err(adev->dev, "numbytes requested %d is over max allowed
%d\n",
+ numbytes, MAX_SW_I2C_COMMANDS);
+ return -EINVAL;
+ }
+
memset(, 0, sizeof(req));
arcturus_fill_eeprom_i2c_req(, true, address, numbytes, data);
--
2.27.0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: Failed to find memory space for buffer eviction
[AMD Public Use]
Maybe we should re-test the problematic piglit test and if it's no longer an
issue, revert:
commit 24562523688bebc7ec17a88271b4e8c3fc337b74
Author: Andrey Grodzovsky
Date: Fri Dec 15 12:09:16 2017 -0500
Revert "drm/amd/amdgpu: set gtt size according to system memory size only"
This reverts commit ba851eed895c76be0eb4260bdbeb7e26f9ccfaa2.
With that change piglit max size tests (running with -t max.*size) are
causing
OOM and hard hang on my CZ with 1GB RAM.
Signed-off-by: Andrey Grodzovsky
Acked-by: Alex Deucher
Reviewed-by: Christian König
Reviewed-by: Roger He
Signed-off-by: Alex Deucher
From: amd-gfx on behalf of Christian
König
Sent: Wednesday, July 15, 2020 5:28 AM
To: Kuehling, Felix ; Koenig, Christian
; amd-gfx list
Subject: Re: Failed to find memory space for buffer eviction
Am 15.07.20 um 04:49 schrieb Felix Kuehling:
> Am 2020-07-14 um 4:28 a.m. schrieb Christian König:
>> Hi Felix,
>>
>> yes I already stumbled over this as well quite recently.
>>
>> See the following patch which I pushed to drm-misc-next just yesterday:
>>
>> commit e04be2310b5eac683ec03b096c0e22c4c2e23593
>> Author: Christian König
>> Date: Mon Jul 6 17:32:55 2020 +0200
>>
>> drm/ttm: further cleanup ttm_mem_reg handling
>>
>> Stop touching the backend private pointer alltogether and
>> make sure we never put the same mem twice by.
>>
>> Signed-off-by: Christian König
>> Reviewed-by: Madhav Chauhan
>> Link:
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.freedesktop.org%2Fpatch%2F375613%2Fdata=02%7C01%7Calexander.deucher%40amd.com%7Ce19192b295fc41a7fb4c08d828a168d4%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637304021017509156sdata=zilZiBrs%2FVrzhZuolVzhLSO2kIBDugp16HT58G7tX8w%3Dreserved=0
>>
>>
>> But this shouldn't have been problematic since we used a dummy value
>> for mem->mm_node in this case.
> Hmm, yeah, I was reading the code wrong. It's possible that I was really
> just out of GTT space. But see below.
It looks like it yes.
>> What could be problematic and result is an overrun is that TTM was
>> buggy and called put_node twice for the same memory.
>>
>> So I've seen that the code needs fixing as well, but I'm not 100% sure
>> how you ran into your problem.
> This is in the KFD eviction test, which deliberately overcommits VRAM in
> order to trigger lots of evictions. It will use some GTT space while BOs
> are evicted. But shouldn't it move them further out of GTT and into
> SYSTEM to free up GTT space?
Yes, exactly that should happen.
But for some reason it couldn't find a candidate to evict and the 14371
pages left are just a bit to small for the buffer.
Regards,
Christian.
> Your change "further cleanup ttm_mem_reg handling" removes a
> mem->mm_node = NULL in ttm_bo_handle_move_mem in exactly the case where
> a BO is moved from GTT to SYSTEM. I think that leads to a later put_node
> call not happening or amdgpu_gtt_mgr_del returning before incrementing
> mgr->available.
>
> I can try if cherry-picking your two fixes will help with the eviction test.
>
> Regards,
>Felix
>
>
>> Regards,
>> Christian.
>>
>> Am 14.07.20 um 02:44 schrieb Felix Kuehling:
>>> I'm running into this problem with the KFD EvictionTest. The log snippet
>>> below looks like it ran out of GTT space for the eviction of a 64MB
>>> buffer. But then it dumps the used and free space and shows plenty of
>>> free space.
>>>
>>> As I understand it, the per-page breakdown of used and free space shown
>>> by TTM is the GART space. So it's not very meaningful.
>>>
>>> What matters more is the GTT space managed by amdgpu_gtt_mgr.c. And
>>> that's where the problem is. It keeps track of available GTT space with
>>> an atomic counter in amdgpu_gtt_mgr.available. It gets decremented in
>>> amdgpu_gtt_mgr_new and incremented in amdgpu_gtt_mgr_del. The trouble
>>> is, that TTM doesn't call the latter for ttm_mem_regs that don't have an
>>> mm_node:
>>>
void ttm_bo_mem_put(struct ttm_buffer_object *bo, struct ttm_mem_reg
*mem)
{
struct ttm_mem_type_manager *man =
>bdev->man[mem->mem_type];
if (mem->mm_node)
(*man->func->put_node)(man, mem);
}
>>> GTT BOs that don't have GART space allocated, don't hate an mm_node. So
>>> the amdgpu_gtt_mgr.available counter doesn't get incremented when an
>>> unmapped GTT BO is freed, and eventually runs out of space.
>>>
>>> Now I know what the problem is, but I don't know how to fix it. Maybe a
>>> dummy-mm_node for unmapped GTT BOs, to trick TTM into calling our
>>> put_node callback? Or a change in TTM to call put_node unconditionally?
>>>
>>> Regards,
>>> Felix
>>>
>>>
>>> [ 360.082552] [TTM] Failed to find memory space for buffer
>>> 0x264c823c eviction
>>> [ 360.090331] [TTM] No space for 264c823c (16384 pages,
>>> 65536K, 64M)
>>> [
Re: [PATCH 13/16] drm/amd/powerplay: apply gfxoff disablement/enablement for all SMU11 ASICs
[AMD Public Use]
Reviewed-by: Alex Deucher
From: Quan, Evan
Sent: Tuesday, July 14, 2020 2:55 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: RE: [PATCH 13/16] drm/amd/powerplay: apply gfxoff
disablement/enablement for all SMU11 ASICs
[AMD Official Use Only - Internal Distribution Only]
Hi Alex,
Can I have a RB for this patch also?
BR
Evan
-Original Message-
From: Quan, Evan
Sent: Monday, July 13, 2020 11:45 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: RE: [PATCH 13/16] drm/amd/powerplay: apply gfxoff
disablement/enablement for all SMU11 ASICs
Ping for this one and patch12, patch2 and patch3
BR
Evan
-Original Message-
From: Quan, Evan
Sent: Friday, July 10, 2020 12:48 PM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Quan, Evan
Subject: [PATCH 13/16] drm/amd/powerplay: apply gfxoff disablement/enablement
for all SMU11 ASICs
Before and after setting gfx clock soft max/min frequency.
Change-Id: I6f828da8de096ebc0ae27eaa89f988def2d547ec
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/powerplay/smu_v11_0.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/smu_v11_0.c
b/drivers/gpu/drm/amd/powerplay/smu_v11_0.c
index c2779d0b51f6..33e0718f2635 100644
--- a/drivers/gpu/drm/amd/powerplay/smu_v11_0.c
+++ b/drivers/gpu/drm/amd/powerplay/smu_v11_0.c
@@ -1758,8 +1758,7 @@ int smu_v11_0_set_soft_freq_limited_range(struct
smu_context *smu,
if (clk_id < 0)
return clk_id;
-if (clk_type == SMU_GFXCLK &&
-adev->asic_type == CHIP_SIENNA_CICHLID)
+if (clk_type == SMU_GFXCLK)
amdgpu_gfx_off_ctrl(adev, false);
if (max > 0) {
@@ -1779,8 +1778,7 @@ int smu_v11_0_set_soft_freq_limited_range(struct
smu_context *smu,
}
out:
-if (clk_type == SMU_GFXCLK &&
-adev->asic_type == CHIP_SIENNA_CICHLID)
+if (clk_type == SMU_GFXCLK)
amdgpu_gfx_off_ctrl(adev, true);
return ret;
--
2.27.0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 2/5] drm/amdgpu: optimize rlcg write for gfx_v10
[AMD Official Use Only - Internal Distribution Only]
Acked-by: Alex Deucher
From: amd-gfx on behalf of Jack Zhang
Sent: Monday, July 13, 2020 10:46 PM
To: amd-gfx@lists.freedesktop.org
Cc: Zhang, Jack (Jian) ; Liu, Leo ;
Zhang, Hawking
Subject: [PATCH 2/5] drm/amdgpu: optimize rlcg write for gfx_v10
For gfx10 boards, except for nv12, other boards take mmio write
rather than rlcg write
---
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 26 +++---
1 file changed, 19 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index c1f8c986380c..a78a6a1b593a 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
@@ -4728,12 +4728,19 @@ static int gfx_v10_0_init_csb(struct amdgpu_device
*adev)
adev->gfx.rlc.funcs->get_csb_buffer(adev, adev->gfx.rlc.cs_ptr);
/* csib */
- WREG32_SOC15_RLC(GC, 0, mmRLC_CSIB_ADDR_HI,
-adev->gfx.rlc.clear_state_gpu_addr >> 32);
- WREG32_SOC15_RLC(GC, 0, mmRLC_CSIB_ADDR_LO,
-adev->gfx.rlc.clear_state_gpu_addr & 0xfffc);
- WREG32_SOC15_RLC(GC, 0, mmRLC_CSIB_LENGTH,
adev->gfx.rlc.clear_state_size);
-
+ if (adev->asic_type == CHIP_NAVI12) {
+ WREG32_SOC15_RLC(GC, 0, mmRLC_CSIB_ADDR_HI,
+ adev->gfx.rlc.clear_state_gpu_addr >> 32);
+ WREG32_SOC15_RLC(GC, 0, mmRLC_CSIB_ADDR_LO,
+ adev->gfx.rlc.clear_state_gpu_addr &
0xfffc);
+ WREG32_SOC15_RLC(GC, 0, mmRLC_CSIB_LENGTH,
adev->gfx.rlc.clear_state_size);
+ } else {
+ WREG32_SOC15(GC, 0, mmRLC_CSIB_ADDR_HI,
+ adev->gfx.rlc.clear_state_gpu_addr >> 32);
+ WREG32_SOC15(GC, 0, mmRLC_CSIB_ADDR_LO,
+ adev->gfx.rlc.clear_state_gpu_addr &
0xfffc);
+ WREG32_SOC15(GC, 0, mmRLC_CSIB_LENGTH,
adev->gfx.rlc.clear_state_size);
+ }
return 0;
}
@@ -5341,7 +5348,12 @@ static int gfx_v10_0_cp_gfx_enable(struct amdgpu_device
*adev, bool enable)
tmp = REG_SET_FIELD(tmp, CP_ME_CNTL, ME_HALT, enable ? 0 : 1);
tmp = REG_SET_FIELD(tmp, CP_ME_CNTL, PFP_HALT, enable ? 0 : 1);
tmp = REG_SET_FIELD(tmp, CP_ME_CNTL, CE_HALT, enable ? 0 : 1);
- WREG32_SOC15_RLC(GC, 0, mmCP_ME_CNTL, tmp);
+
+ if (adev->asic_type == CHIP_NAVI12) {
+ WREG32_SOC15_RLC(GC, 0, mmCP_ME_CNTL, tmp);
+ } else {
+ WREG32_SOC15(GC, 0, mmCP_ME_CNTL, tmp);
+ }
for (i = 0; i < adev->usec_timeout; i++) {
if (RREG32_SOC15(GC, 0, mmCP_STAT) == 0)
--
2.17.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfxdata=02%7C01%7Calexander.deucher%40amd.com%7Ce334ea6c4d504943153c08d827a02c4b%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637302916203617712sdata=zj8wkoVYWIyGZ8Y0Dtv8JQ7p6C3RzV%2B%2BnbKFhLYtHDg%3Dreserved=0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 1/5] drm/amd/sriov skip jped ip block and close pgcg flags
[AMD Public Use]
Acked-by: Alex Deucher
From: amd-gfx on behalf of Jack Zhang
Sent: Monday, July 13, 2020 10:45 PM
To: amd-gfx@lists.freedesktop.org
Cc: Zhang, Jack (Jian) ; Liu, Leo ;
Zhang, Hawking
Subject: [PATCH 1/5] drm/amd/sriov skip jped ip block and close pgcg flags
For SIENNA_CICHLID SRIOV, jpeg and pgcp is not supported.
Signed-off-by: Jack Zhang
---
drivers/gpu/drm/amd/amdgpu/nv.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/nv.c b/drivers/gpu/drm/amd/amdgpu/nv.c
index a7cfe3ac7cb6..7f34a2f25700 100644
--- a/drivers/gpu/drm/amd/amdgpu/nv.c
+++ b/drivers/gpu/drm/amd/amdgpu/nv.c
@@ -504,7 +504,9 @@ int nv_set_ip_blocks(struct amdgpu_device *adev)
amdgpu_device_ip_block_add(adev, _v10_0_ip_block);
amdgpu_device_ip_block_add(adev, _v5_2_ip_block);
amdgpu_device_ip_block_add(adev, _v3_0_ip_block);
- amdgpu_device_ip_block_add(adev, _v3_0_ip_block);
+ if (!amdgpu_sriov_vf(adev))
+ amdgpu_device_ip_block_add(adev, _v3_0_ip_block);
+
if (adev->enable_mes)
amdgpu_device_ip_block_add(adev, _v10_1_ip_block);
break;
@@ -732,7 +734,13 @@ static int nv_common_early_init(void *handle)
adev->pg_flags = AMD_PG_SUPPORT_VCN |
AMD_PG_SUPPORT_VCN_DPG |
AMD_PG_SUPPORT_JPEG |
- AMD_PG_SUPPORT_ATHUB;
+ AMD_PG_SUPPORT_ATHUB |
+ AMD_PG_SUPPORT_MMHUB;
+ if (amdgpu_sriov_vf(adev)) {
+ /* hypervisor control CG and PG enablement */
+ adev->cg_flags = 0;
+ adev->pg_flags = 0;
+ }
adev->external_rev_id = adev->rev_id + 0x28;
break;
default:
--
2.17.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfxdata=02%7C01%7Calexander.deucher%40amd.com%7C78d9223013c74c21b2c708d827a01820%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637302915854056774sdata=Z6SAzQ%2FKFcyJb%2FLPN3iUIBnqyacMeWG8Pjnu2LfioW8%3Dreserved=0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amd/display: Fix compilation error on dcn3
[AMD Public Use]
Reviewed-by: Alex Deucher
From: Siqueira, Rodrigo
Sent: Tuesday, July 14, 2020 8:06 AM
To: amd-gfx@lists.freedesktop.org
Cc: Wentland, Harry ; Li, Sun peng (Leo)
; Deucher, Alexander ; Teng, Rui
; Laktyushkin, Dmytro ;
Kazlauskas, Nicholas ; Lee, Alvin
Subject: [PATCH] drm/amd/display: Fix compilation error on dcn3
We have a compilation error when compiling dcn30_resource.c due to a
missing field in _vcs_dpi_soc_bounding_box_st. This commit fixes this
issue by introducing the required field and include file.
Cc: Rui Teng
Cc: Dmytro Laktyushkin
Cc: Nicholas Kazlauskas
Cc: Alvin Lee
Signed-off-by: Rodrigo Siqueira
---
drivers/gpu/drm/amd/display/dc/dml/display_mode_structs.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/dml/display_mode_structs.h
b/drivers/gpu/drm/amd/display/dc/dml/display_mode_structs.h
index 0fac7f754604..6ab74640c0da 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/display_mode_structs.h
+++ b/drivers/gpu/drm/amd/display/dc/dml/display_mode_structs.h
@@ -24,6 +24,7 @@
*/
#include "dc_features.h"
+#include "display_mode_enums.h"
#ifndef __DISPLAY_MODE_STRUCTS_H__
#define __DISPLAY_MODE_STRUCTS_H__
@@ -120,6 +121,7 @@ struct _vcs_dpi_soc_bounding_box_st {
double urgent_latency_adjustment_fabric_clock_reference_mhz;
bool disable_dram_clock_change_vactive_support;
bool allow_dram_clock_one_display_vactive;
+ enum self_refresh_affinity
allow_dram_self_refresh_or_dram_clock_change_in_vblank;
};
struct _vcs_dpi_ip_params_st {
--
2.27.0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amd/display: add dmcub check on RENOIR
[AMD Public Use] Acked-by: Alex Deucher From: Aaron Ma Sent: Wednesday, July 8, 2020 4:16 AM To: Wentland, Harry ; Li, Sun peng (Leo) ; Deucher, Alexander ; Koenig, Christian ; airl...@linux.ie ; dan...@ffwll.ch ; amd-gfx@lists.freedesktop.org ; dri-de...@lists.freedesktop.org ; linux-ker...@vger.kernel.org ; mapen...@gmail.com ; aaron...@canonical.com Subject: [PATCH] drm/amd/display: add dmcub check on RENOIR RENOIR loads dmub fw not dmcu, check dmcu only will prevent loading iram, it breaks backlight control. Bug: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.kernel.org%2Fshow_bug.cgi%3Fid%3D208277data=02%7C01%7Calexander.deucher%40amd.com%7Cf922a1848f1f4cc4934f08d823174036%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637297930080282163sdata=limstWv5pwvdqDRpKoKpCZcutV4pmqhdqR7CFEimR2Q%3Dreserved=0 Signed-off-by: Aaron Ma --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index 10ac8076d4f2..db5e0bb0d935 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -1358,7 +1358,7 @@ static int dm_late_init(void *handle) struct dmcu *dmcu = NULL; bool ret; - if (!adev->dm.fw_dmcu) + if (!adev->dm.fw_dmcu && !adev->dm.dmub_fw) return detect_mst_link_for_all_connectors(adev->ddev); dmcu = adev->dm.dc->res_pool->dmcu; -- 2.25.1 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu/swSMU: drop pm_enabled check in set mp1 state
[AMD Public Use]
Ah, yes, indeed.
Thanks,
Alex
From: Quan, Evan
Sent: Monday, July 6, 2020 9:31 PM
To: Alex Deucher ; amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: RE: [PATCH] drm/amdgpu/swSMU: drop pm_enabled check in set mp1 state
[AMD Official Use Only - Internal Distribution Only]
I think you may wrongly treated the "pm_enabled" as "dpm_enabled".
pm_enabled should be always true unless user specifies "dpm=0" on module
loading.
-Original Message-
From: amd-gfx On Behalf Of Alex Deucher
Sent: Tuesday, July 7, 2020 3:16 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: [PATCH] drm/amdgpu/swSMU: drop pm_enabled check in set mp1 state
We need to set the mp1 state in PCI shutdown and certain reset cases which
happens after we've already suspended the SMU. SMU suspend sets pm_enabled to
false which prevents this code from being run.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/powerplay/amdgpu_smu.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c
b/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c
index fe4948aa662f..0ed75a9897eb 100644
--- a/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c
+++ b/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c
@@ -1924,9 +1924,6 @@ int smu_set_mp1_state(struct smu_context *smu,
uint16_t msg;
int ret;
-if (!smu->pm_enabled)
-return -EOPNOTSUPP;
-
mutex_lock(>mutex);
switch (mp1_state) {
--
2.25.4
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfxdata=02%7C01%7Cevan.quan%40amd.com%7C84723b854666ac1f08d821e11cf8%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637296598083021484sdata=bD1UlSdYqXuPoDoTCvGZHRJr2F6DoJu2LHN6v5p4%2FoA%3Dreserved=0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 2/2] drm/amdgpu: add TMR destory function for psp
[AMD Public Use]
Series is:
Reviewed-by: Alex Deucher
From: amd-gfx on behalf of Huang Rui
Sent: Tuesday, June 30, 2020 6:30 AM
To: amd-gfx@lists.freedesktop.org
Cc: Huang, Ray
Subject: [PATCH 2/2] drm/amdgpu: add TMR destory function for psp
TMR is required to be destoried with GFX_CMD_ID_DESTROY_TMR while the
system goes to suspend. Otherwise, PSP may return the failure state
(0x007) on Gfx-2-PSP command GFX_CMD_ID_SETUP_TMR after do multiple
times suspend/resume.
Signed-off-by: Huang Rui
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 57 +++--
1 file changed, 53 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
index e57a53d5ca96..23ebb50b1a19 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
@@ -430,6 +430,52 @@ static int psp_tmr_load(struct psp_context *psp)
return ret;
}
+static void psp_prep_tmr_unload_cmd_buf(struct psp_context *psp,
+ struct psp_gfx_cmd_resp *cmd)
+{
+ if (amdgpu_sriov_vf(psp->adev))
+ cmd->cmd_id = GFX_CMD_ID_DESTROY_VMR;
+ else
+ cmd->cmd_id = GFX_CMD_ID_DESTROY_TMR;
+}
+
+static int psp_tmr_unload(struct psp_context *psp)
+{
+ int ret;
+ struct psp_gfx_cmd_resp *cmd;
+
+ cmd = kzalloc(sizeof(struct psp_gfx_cmd_resp), GFP_KERNEL);
+ if (!cmd)
+ return -ENOMEM;
+
+ psp_prep_tmr_unload_cmd_buf(psp, cmd);
+ DRM_INFO("free PSP TMR buffer\n");
+
+ ret = psp_cmd_submit_buf(psp, NULL, cmd,
+psp->fence_buf_mc_addr);
+
+ kfree(cmd);
+
+ return ret;
+}
+
+static int psp_tmr_terminate(struct psp_context *psp)
+{
+ int ret;
+ void *tmr_buf;
+ void **pptr;
+
+ ret = psp_tmr_unload(psp);
+ if (ret)
+ return ret;
+
+ /* free TMR memory buffer */
+ pptr = amdgpu_sriov_vf(psp->adev) ? _buf : NULL;
+ amdgpu_bo_free_kernel(>tmr_bo, >tmr_mc_addr, pptr);
+
+ return 0;
+}
+
static void psp_prep_asd_load_cmd_buf(struct psp_gfx_cmd_resp *cmd,
uint64_t asd_mc, uint32_t size)
{
@@ -1866,8 +1912,6 @@ static int psp_hw_fini(void *handle)
{
struct amdgpu_device *adev = (struct amdgpu_device *)handle;
struct psp_context *psp = >psp;
- void *tmr_buf;
- void **pptr;
int ret;
if (psp->adev->psp.ta_fw) {
@@ -1883,10 +1927,9 @@ static int psp_hw_fini(void *handle)
return ret;
}
+ psp_tmr_terminate(psp);
psp_ring_destroy(psp, PSP_RING_TYPE__KM);
- pptr = amdgpu_sriov_vf(psp->adev) ? _buf : NULL;
- amdgpu_bo_free_kernel(>tmr_bo, >tmr_mc_addr, pptr);
amdgpu_bo_free_kernel(>fw_pri_bo,
>fw_pri_mc_addr, >fw_pri_buf);
amdgpu_bo_free_kernel(>fence_buf_bo,
@@ -1939,6 +1982,12 @@ static int psp_suspend(void *handle)
return ret;
}
+ ret = psp_tmr_terminate(psp);
+ if (ret) {
+ DRM_ERROR("Falied to terminate tmr\n");
+ return ret;
+ }
+
ret = psp_ring_stop(psp, PSP_RING_TYPE__KM);
if (ret) {
DRM_ERROR("PSP ring stop failed\n");
--
2.25.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfxdata=02%7C01%7Calexander.deucher%40amd.com%7C282cd5829fbe4fca8ac708d81ce0cdbb%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637291099162588481sdata=UfOBa7Xaa6qvWClFnYB4OSngc8k0YyUmDCwtKmZ5BQQ%3Dreserved=0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu: correct discovery_tmr_size init val
[AMD Public Use]
You might want to add a comment to the code here. It looks wrong to use the
OFFSET.
Alex
From: amd-gfx on behalf of Wenhui.Sheng
Sent: Monday, June 29, 2020 2:07 AM
To: amd-gfx@lists.freedesktop.org
Cc: Sheng, Wenhui ; Zhang, Hawking
Subject: [PATCH] drm/amdgpu: correct discovery_tmr_size init val
From: Wenhui Sheng
The legacy way to initialize discovery_tmr_size
is using DISCOVERY_TMR_SIZE, while after we reduce
DISCOVERY_TMR_SIZE from 64KB to 4KB, variable
discovery_tmr_size is also reduced to 4KB, this is not
correct, it still should be 64KB, discovery_tmr_size
will be used to calculate ip_discovery reserved mem's
start address and size.
Using DISCOVERY_TMR_OFFSET to init discovery_tmr_size instead.
Signed-off-by: Wenhui Sheng
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 7d51768684dd..56beafbd3ab9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1872,7 +1872,7 @@ static int amdgpu_ttm_reserve_tmr(struct amdgpu_device
*adev)
adev->discovery_tmr_size =
amdgpu_atomfirmware_get_fw_reserved_fb_size(adev);
if (!adev->discovery_tmr_size)
- adev->discovery_tmr_size = DISCOVERY_TMR_SIZE;
+ adev->discovery_tmr_size = DISCOVERY_TMR_OFFSET;
if (mem_train_support) {
/* reserve vram for mem train according to TMR location */
--
2.17.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfxdata=02%7C01%7Calexander.deucher%40amd.com%7Cba68c480e1fc4e73952408d81bf2ca8a%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637290077543935012sdata=R0g%2FzsOg%2BoH5%2BccXgnGAhRd0JfMgCTuXlv6yuIQSVuY%3Dreserved=0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 3/3] drm/amdgpu: SI support for UVD and VCE power managment
[AMD Public Use]
Series is:
Reviewed-by: Alex Deucher
From: Jivin, Alex
Sent: Wednesday, June 24, 2020 4:31 PM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: [PATCH 3/3] drm/amdgpu: SI support for UVD and VCE power managment
Port functionality from the Radeon driver to support
UVD and VCE power management.
Signed-off-by: Alex Jivin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 67 +++---
drivers/gpu/drm/amd/amdgpu/si_dpm.c| 19
2 files changed, 68 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
index 347b06d3c140..26c8e39a78bd 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
@@ -3558,21 +3558,36 @@ void amdgpu_dpm_enable_uvd(struct amdgpu_device *adev,
bool enable)
{
int ret = 0;
- ret = amdgpu_dpm_set_powergating_by_smu(adev, AMD_IP_BLOCK_TYPE_UVD,
!enable);
- if (ret)
- DRM_ERROR("Dpm %s uvd failed, ret = %d. \n",
- enable ? "enable" : "disable", ret);
-
- /* enable/disable Low Memory PState for UVD (4k videos) */
- if (adev->asic_type == CHIP_STONEY &&
- adev->uvd.decode_image_width >= WIDTH_4K) {
- struct pp_hwmgr *hwmgr = adev->powerplay.pp_handle;
+ if (adev->family == AMDGPU_FAMILY_SI) {
+ if (enable) {
+ mutex_lock(>pm.mutex);
+ adev->pm.dpm.uvd_active = true;
+ adev->pm.dpm.state = POWER_STATE_TYPE_INTERNAL_UVD;
+ mutex_unlock(>pm.mutex);
+ } else {
+ mutex_lock(>pm.mutex);
+ adev->pm.dpm.uvd_active = false;
+ mutex_unlock(>pm.mutex);
+ }
- if (hwmgr && hwmgr->hwmgr_func &&
- hwmgr->hwmgr_func->update_nbdpm_pstate)
- hwmgr->hwmgr_func->update_nbdpm_pstate(hwmgr,
- !enable,
- true);
+ amdgpu_pm_compute_clocks(adev);
+ } else {
+ ret = amdgpu_dpm_set_powergating_by_smu(adev,
AMD_IP_BLOCK_TYPE_UVD, !enable);
+ if (ret)
+ DRM_ERROR("Dpm %s uvd failed, ret = %d. \n",
+ enable ? "enable" : "disable", ret);
+
+ /* enable/disable Low Memory PState for UVD (4k videos) */
+ if (adev->asic_type == CHIP_STONEY &&
+ adev->uvd.decode_image_width >= WIDTH_4K) {
+ struct pp_hwmgr *hwmgr = adev->powerplay.pp_handle;
+
+ if (hwmgr && hwmgr->hwmgr_func &&
+ hwmgr->hwmgr_func->update_nbdpm_pstate)
+ hwmgr->hwmgr_func->update_nbdpm_pstate(hwmgr,
+ !enable,
+ true);
+ }
}
}
@@ -3580,10 +3595,26 @@ void amdgpu_dpm_enable_vce(struct amdgpu_device *adev,
bool enable)
{
int ret = 0;
- ret = amdgpu_dpm_set_powergating_by_smu(adev, AMD_IP_BLOCK_TYPE_VCE,
!enable);
- if (ret)
- DRM_ERROR("Dpm %s vce failed, ret = %d. \n",
- enable ? "enable" : "disable", ret);
+ if (adev->family == AMDGPU_FAMILY_SI) {
+ if (enable) {
+ mutex_lock(>pm.mutex);
+ adev->pm.dpm.vce_active = true;
+ /* XXX select vce level based on ring/task */
+ adev->pm.dpm.vce_level = AMD_VCE_LEVEL_AC_ALL;
+ mutex_unlock(>pm.mutex);
+ } else {
+ mutex_lock(>pm.mutex);
+ adev->pm.dpm.vce_active = false;
+ mutex_unlock(>pm.mutex);
+ }
+
+ amdgpu_pm_compute_clocks(adev);
+ } else {
+ ret = amdgpu_dpm_set_powergating_by_smu(adev,
AMD_IP_BLOCK_TYPE_VCE, !enable);
+ if (ret)
+ DRM_ERROR("Dpm %s vce failed, ret = %d. \n",
+ enable ? "enable" : "disable", ret);
+ }
}
void amdgpu_pm_print_power_states(struct amdgpu_device *adev)
diff --git a/drivers/gpu/drm/amd/amdgpu/si_dpm.c
b/drivers/gpu/drm/amd/amdgpu/si_dpm.c
index c00ba4b23c9a..ea914b256ebd 100644
--- a/drivers/gpu/drm/amd/amdgpu/si_dpm
Re: [PATCH 1/2] drm/amd/powerplay: change method to set board parameters
[AMD Public Use] Series is: Acked-by: Alex Deucher From: amd-gfx on behalf of Likun Gao Sent: Wednesday, June 24, 2020 2:35 AM To: amd-gfx@lists.freedesktop.org Cc: Gao, Likun ; Feng, Kenneth ; Zhang, Hawking Subject: [PATCH 1/2] drm/amd/powerplay: change method to set board parameters From: Likun Gao Copy board parameters directly instead of set each parameter for sienna_cichlid. Signed-off-by: Likun Gao --- .../drm/amd/powerplay/sienna_cichlid_ppt.c| 89 +-- 1 file changed, 2 insertions(+), 87 deletions(-) diff --git a/drivers/gpu/drm/amd/powerplay/sienna_cichlid_ppt.c b/drivers/gpu/drm/amd/powerplay/sienna_cichlid_ppt.c index 769e031d489a..693ad8963d0a 100644 --- a/drivers/gpu/drm/amd/powerplay/sienna_cichlid_ppt.c +++ b/drivers/gpu/drm/amd/powerplay/sienna_cichlid_ppt.c @@ -394,7 +394,6 @@ static int sienna_cichlid_append_powerplay_table(struct smu_context *smu) PPTable_t *smc_pptable = table_context->driver_pptable; struct atom_smc_dpm_info_v4_9 *smc_dpm_table; int index, ret; - int i; index = get_index_into_master_table(atom_master_list_of_data_tables_v2_1, smc_dpm_info); @@ -405,92 +404,8 @@ static int sienna_cichlid_append_powerplay_table(struct smu_context *smu) return ret; memcpy(smc_pptable->I2cControllers, smc_dpm_table->I2cControllers, - sizeof(I2cControllerConfig_t) * NUM_I2C_CONTROLLERS); - - /* SVI2 Board Parameters */ - smc_pptable->VddGfxVrMapping = smc_dpm_table->VddGfxVrMapping; - smc_pptable->VddSocVrMapping = smc_dpm_table->VddSocVrMapping; - smc_pptable->VddMem0VrMapping = smc_dpm_table->VddMem0VrMapping; - smc_pptable->VddMem1VrMapping = smc_dpm_table->VddMem1VrMapping; - smc_pptable->GfxUlvPhaseSheddingMask = smc_dpm_table->GfxUlvPhaseSheddingMask; - smc_pptable->SocUlvPhaseSheddingMask = smc_dpm_table->SocUlvPhaseSheddingMask; - smc_pptable->VddciUlvPhaseSheddingMask = smc_dpm_table->VddciUlvPhaseSheddingMask; - smc_pptable->MvddUlvPhaseSheddingMask = smc_dpm_table->MvddUlvPhaseSheddingMask; - - /* Telemetry Settings */ - smc_pptable->GfxMaxCurrent = smc_dpm_table->GfxMaxCurrent; - smc_pptable->GfxOffset = smc_dpm_table->GfxOffset; - smc_pptable->Padding_TelemetryGfx = smc_dpm_table->Padding_TelemetryGfx; - smc_pptable->SocMaxCurrent = smc_dpm_table->SocMaxCurrent; - smc_pptable->SocOffset = smc_dpm_table->SocOffset; - smc_pptable->Padding_TelemetrySoc = smc_dpm_table->Padding_TelemetrySoc; - smc_pptable->Mem0MaxCurrent = smc_dpm_table->Mem0MaxCurrent; - smc_pptable->Mem0Offset = smc_dpm_table->Mem0Offset; - smc_pptable->Padding_TelemetryMem0 = smc_dpm_table->Padding_TelemetryMem0; - smc_pptable->Mem1MaxCurrent = smc_dpm_table->Mem1MaxCurrent; - smc_pptable->Mem1Offset = smc_dpm_table->Mem1Offset; - smc_pptable->Padding_TelemetryMem1 = smc_dpm_table->Padding_TelemetryMem1; - smc_pptable->MvddRatio = smc_dpm_table->MvddRatio; - - /* GPIO Settings */ - smc_pptable->AcDcGpio = smc_dpm_table->AcDcGpio; - smc_pptable->AcDcPolarity = smc_dpm_table->AcDcPolarity; - smc_pptable->VR0HotGpio = smc_dpm_table->VR0HotGpio; - smc_pptable->VR0HotPolarity = smc_dpm_table->VR0HotPolarity; - smc_pptable->VR1HotGpio = smc_dpm_table->VR1HotGpio; - smc_pptable->VR1HotPolarity = smc_dpm_table->VR1HotPolarity; - smc_pptable->GthrGpio = smc_dpm_table->GthrGpio; - smc_pptable->GthrPolarity = smc_dpm_table->GthrPolarity; - - /* LED Display Settings */ - smc_pptable->LedPin0 = smc_dpm_table->LedPin0; - smc_pptable->LedPin1 = smc_dpm_table->LedPin1; - smc_pptable->LedPin2 = smc_dpm_table->LedPin2; - smc_pptable->LedEnableMask = smc_dpm_table->LedEnableMask; - smc_pptable->LedPcie = smc_dpm_table->LedPcie; - smc_pptable->LedError = smc_dpm_table->LedError; - smc_pptable->LedSpare1[0] = smc_dpm_table->LedSpare1[0]; - smc_pptable->LedSpare1[1] = smc_dpm_table->LedSpare1[1]; - - /* GFXCLK PLL Spread Spectrum */ - smc_pptable->PllGfxclkSpreadEnabled = smc_dpm_table->PllGfxclkSpreadEnabled; - smc_pptable->PllGfxclkSpreadPercent = smc_dpm_table->PllGfxclkSpreadPercent; - smc_pptable->PllGfxclkSpreadFreq = smc_dpm_table->PllGfxclkSpreadFreq; - - /* GFXCLK DFLL Spread Spectrum */ - smc_pptable->DfllGfxclkSpreadEnabled = smc_dpm_table->DfllGfxclkSpreadEnabled; - smc_pptable->DfllGfxclkSpreadPercent = smc_dpm_table->DfllGfxclkSpreadPercent; - smc_pptable->DfllGfxclkSpreadFreq = smc_dpm_table->DfllGfxclkSpreadFreq; - - /* UCLK Spread Spectrum */ - smc_pptable->UclkSpreadEnabled = smc_dpm_table->UclkSpreadEnabled; - smc_pptable->UclkSpreadPercent = smc_dpm_table->UclkSpreadPercent; -
Re: [PATCH 1/1] drm/amd/powerplay: Fix DCEFCLK related compilation error for arcturus
[AMD Public Use] No problem. Reviewed-by: Alex Deucher From: Das, Nirmoy Sent: Tuesday, June 23, 2020 12:04 PM To: Nirmoy Das ; amd-gfx@lists.freedesktop.org Cc: Deucher, Alexander ; Das, Nirmoy Subject: Re: [PATCH 1/1] drm/amd/powerplay: Fix DCEFCLK related compilation error for arcturus On 6/23/20 5:59 PM, Nirmoy Das wrote: > arcturus doesn't support DCEFCLK > > Fixes: c67c791cd87d (drm/amd/powerplay: return current DCEFCLK on sysfs read) Hi Alex, Can you please squash this with c67c791cd87d (drm/amd/powerplay: return current DCEFCLK on sysfs read) I was bit too confident that arcturus changes would just work. Regards, Nirmoy > > Signed-off-by: Nirmoy Das > --- > drivers/gpu/drm/amd/powerplay/arcturus_ppt.c | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/drivers/gpu/drm/amd/powerplay/arcturus_ppt.c > b/drivers/gpu/drm/amd/powerplay/arcturus_ppt.c > index daeae14fd380..d93f8a43a96f 100644 > --- a/drivers/gpu/drm/amd/powerplay/arcturus_ppt.c > +++ b/drivers/gpu/drm/amd/powerplay/arcturus_ppt.c > @@ -962,9 +962,6 @@ static int arcturus_get_smu_metrics_data(struct > smu_context *smu, >case METRICS_CURR_FCLK: >*value = metrics->CurrClock[PPCLK_FCLK]; >break; > - case METRICS_CURR_DCEFCLK: > - *value = metrics->CurrClock[PPCLK_DCEFCLK]; > - break; >case METRICS_AVERAGE_GFXCLK: >*value = metrics->AverageGfxclkFrequency; >break; ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
