On 7/21/21 9:20 PM, Evan Quan wrote:
The customized OD settings can be divided into two parts: those
committed ones and non-committed ones.
- For those changes which had been fed to SMU before S3/S4/Runpm
suspend kicked, they are committed changes. They should be properly
restored an
9faec54ae4bc2fff68bcd0befa93ace8256ce)
>> both without and with my patches reapplied.
>> So the problem must be related to some commit that is present in the
>> amd-staging-drm-next but not in the mainline.
>>
>>
>> Paweł Gronowski
>>
>> On Thu, Jul
class/drm/card0/device/pp_od_clk_voltage'
>>
>> Which makes the sh hang with 100% usage.
>>
>> The issue does not happen on the mainline
>> (d8b9faec54ae4bc2fff68bcd0befa93ace8256ce)
>> both without and with my patches reapplied.
>> So the problem mus
Thanks Evan! I can confirm that this resolved the following GitLab
issue. Thanks for CC'ing me!
https://gitlab.freedesktop.org/drm/amd/-/issues/1243
Series is Tested-by: Matt Coffin
On 8/2/20 10:46 PM, Evan Quan wrote:
> As VCN related dpm table setup needs VCN be in PG ungate sta
lists.freedesktop.org/archives/amd-gfx/2020-August/052245.html
> https://lists.freedesktop.org/archives/amd-gfx/2020-August/052246.html
>
> BR,
> Evan
> -Original Message-
> From: Quan, Evan
> Sent: Friday, July 31, 2020 9:20 AM
> To: Matt Coffin ; amd-gfx@lists.free
).
Fixes: edad8312cbbf ("drm/amdgpu: fix system hang issue during GPU")
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1245
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/
On 8/12/20 9:55 AM, Alex Deucher wrote:
> This also broke GPU overclocking.
The fix for the `pp_od_clk_voltage` interface was actually quite simple,
and the bug was limited to that function. The patch just messed up the
return value (which was supposed to be the # of bytes consumed). It was
just r
while (isspace(*tmp_str))
> tmp_str++;
> }
>
> Best Regards
> Dennis Li
> -Original Message-
> From: Matt Coffin
> Sent: Friday, August 14, 2020 9:15 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Koenig, Christian
ho 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 ret
ewline, and a nul-terminator, '\n\0', as is the case for `echo 's 1
900' > pp_od_clk_voltage` since the recent rebase.
Signed-off-by: Matt Coffin
---
drivers/gpu/drm/amd/pm/amdgpu_pm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/pm/amdgpu_pm.c
Hello all,
Thought I'd chime in here. While I can't speak to the issue the GitLab
reporter was experiencing, I can say that I get some performance hit
(expected) from this when using multiple monitors with DRI_PRIME. When
the second monitor is active (with something rendering to it with
relative
Sorry to bother you guys, but trying to learn about some of these
things, and I'm tracking the issue this relates to pretty closely on GitLab.
What does DAL stand for in this context?
Thanks in advance for the help,
Matt
On 9/24/20 9:38 PM, Quan, Evan wrote:
> [AMD Official Use Only - Internal D
Fri, Sep 25, 2020 at 5:05 PM Matt Coffin wrote:
>>
>> Sorry to bother you guys, but trying to learn about some of these
>> things, and I'm tracking the issue this relates to pretty closely on GitLab.
>>
>> What does DAL stand for in this context?
>
> DA
9eb213befdcc71
Signed-off-by: Evan Quan
Reviewed-by: Alex Deucher
Thanks everyone, and cheers,
Matt Coffin
-BEGIN PGP SIGNATURE-
iQIzBAEBCAAdFiEEwz6NkrTNYgbdBT2N4mzKau7FyAcFAl8i2FAACgkQ4mzKau7F
yAfhzQ//a4EgvriD6AdSFUgYmmdMnf1iN+cIDj8JnTuoOgRs
ion in
`dmesg` from the kernel.
It appeared to work at least ONCE, but potentially not after.
This is not unique to Navi, and caused the problem on a POLARIS10 card
as well.
Sorry for the bad news, and thanks for any insight you may have,
Matt Coffin
On 7/29/20 8:53 PM, Alex Deucher wrote:
>
odn_edit_dpm_table.
> The 'parameter' array is populated the same way as the original code did.
> Since
> the amdgpu_dpm_odn_edit_dpm_table is reached, I think that your problem is
> unfortunately caused by something else.
>
>
> Paweł Gronowski
>
> On Thu, Ju
Hello all,
I just bisected an issue introduced recently for me where I get screen
corruption before even getting a TTY, and it came down to this commit.
I've got a Navi10 card, and after this commit all that is displayed is a
blank screen (with some obvious corruption artifacts), before I even ge
Thanks for the quick resolution! Might want to add a Fixes header just
for reference when people are reading commit messages?
I can confirm that this fixed the issue introduced by that previous
patch, though!
Patch is Tested-by: Matt Coffin
On 10/20/20 12:48 AM, Yifan Zhang wrote:
> [
On Thu Jan 26, 2023 at 11:26 AM MST, Alex Deucher wrote:
> I'm following up with the SMU teams. Will get back to you when I know more.
Hey again guys,
I'm still relatively stuck on this, both due to being confused the
*seemingly* out-of-date information in the pm/inc/smu_v13_0_0_pptable.h
header
Hello again,
I've been working on OverDrive support for smu13, as you probably
already know. In that endeavor, it also contains the following:
1. I've come up with a few patterns that I think will reduce the
amount of boilerplate and SMU-specific code required to do
implement these interfaces in
On 1/9/23 23:48, Quan, Evan wrote:
[AMD Official Use Only - General]
We need these to address the fan speed setting failure reported for the new
SMU13 asics.
My opinion shouldn't matter much given sparseness of activity, but,
despite his... short tonality, I agree with Lijo's assessment there.
On Wed Jan 11, 2023 at 7:47 AM MST, Alex Deucher wrote:
> On Wed, Jan 11, 2023 at 8:23 AM Quan, Evan wrote:
> >
> > [AMD Official Use Only - General]
> >
> > Regarding the manual fan speed setting issue targeted by this patch, the
> > SCPM feature of the new SMU13 asics prevents us from toggling
[Why]
Before this patch, the smu_v11_0 power limit setting function
incorrectly always thought that TDPODLimit was 0 on navi10 cards. This
meant that between 5.3 and 5.4, when the power limit started being
obeyed, one could no longer set higher power limits for navi10.
[How]
Just as for vega20, we
, and introduce SMU code which would not play nicely with new
ASICs.
Matt Coffin (3):
drm/amdgpu/navi10: implement sclk/mclk OD via pp_od_clk_voltage
drm/amdgpu/navi10: implement GFXCLK_CURVE overdrive
drm/amdgpu/navi10: Implement od clk printing
drivers/gpu/drm/amd/powerplay/inc/smu_v11_0.h
0_PEAK_SCLK_XL(1625)
+#define NAVI10_VOLTAGE_SCALE (4)
+
extern void navi10_set_ppt_funcs(struct smu_context *smu);
#endif
--
2.23.0
From e091c4085ecc669ea907fe5d8515f14586863f9b Mon Sep 17 00:00:00 2001
Message-Id:
In-Reply-To:
References:
From: Matt Coffin
Date: Wed, 6
IVE, 0,
table_context->overdrive_table, false);
+ if (ret) {
+ pr_err("Failed to export overdrive table!\n");
+ return ret;
+ }
+ }
+ ret = smu_update_table(smu, SMU_TABLE_OVERDRIVE, 0,
table_context-&g
[Why]
Before this patch, navi10 overdrive settings could not be printed via
pp_od_clk_voltage
[How]
Implement printing for the overdrive settings for the following clocks
in navi10's ppt print_clk_levels implementation:
* SMU_OD_SCLK
* SMU_OD_MCLK
* SMU_OD_VDDC_CURVE
---
drivers/gpu/drm/amd/powe
Hey guys,
This patch caused some kind of reversion with smu_reset on Navi10. I'm
no expert since everything I know comes from just reading through the
code, so this could be some kind of intended behavior, but after this
patch, if you write a pptable to the sysfs pp_table interface on navi10,
th
, and introduce SMU code which would not play nicely with new
ASICs.
v2: rebase off latest code, and remove an incorrect bounds check
Matt Coffin (3):
drm/amdgpu/navi10: implement sclk/mclk OD via pp_od_clk_voltage
drm/amdgpu/navi10: implement GFXCLK_CURVE overdrive
drm/amdgpu/navi10
[Why]
Before this patch, there was no way to use pp_od_clk_voltage on navi
[How]
Similar to the vega20 implementation, but using the common smc_v11_0
headers, implemented the pp_od_clk_voltage API for navi10's pptable
implementation
---
drivers/gpu/drm/amd/powerplay/inc/smu_v11_0.h | 2 +
drive
[Why]
Before this patch, there was no way to set the gfxclk voltage curve in
the overdrive settings for navi10 through pp_od_clk_voltage
[How]
Add the required implementation to navi10's ppt dpm table editing
implementation, similar to the vega20 implementation and interface.
---
drivers/gpu/drm/
[Why]
Before this patch, navi10 overdrive settings could not be printed via
pp_od_clk_voltage
[How]
Implement printing for the overdrive settings for the following clocks
in navi10's ppt print_clk_levels implementation:
* SMU_OD_SCLK
* SMU_OD_MCLK
* SMU_OD_VDDC_CURVE
---
drivers/gpu/drm/amd/powe
[Why]
On Navi10, and presumably arcterus, updating pp_table via sysfs would
not re-scale the maximum possible power limit one can set. On navi10,
the SMU code ignored the power percentage overdrive setting entirely,
and would not allow you to exceed the default power limit at all.
[How]
Adding a f
[Why]
Before this patch, there was no way to set the gfxclk voltage curve in
the overdrive settings for navi10 through pp_od_clk_voltage
[How]
Add the required implementation to navi10's ppt dpm table editing
implementation, similar to the vega20 implementation and interface.
Signed-off-by:
[Why]
Before this patch, there was no way to use pp_od_clk_voltage on navi
[How]
Similar to the vega20 implementation, but using the common smc_v11_0
headers, implemented the pp_od_clk_voltage API for navi10's pptable
implementation
Signed-off-by: Matt Coffin
---
drivers/gpu/drm/amd/powe
[Why]
Before this patch, navi10 overdrive settings could not be printed via
pp_od_clk_voltage
[How]
Implement printing for the overdrive settings for the following clocks
in navi10's ppt print_clk_levels implementation:
* SMU_OD_SCLK
* SMU_OD_MCLK
* SMU_OD_VDDC_CURVE
Signed-off-by: Matt C
function to the SMU interface to get the pptable version of the
default power limit allows ASIC-specific code to provide the correct
maximum-settable power limit for the current pptable.
Signed-off-by: Matt Coffin
---
drivers/gpu/drm/amd/powerplay/amdgpu_smu.c| 12 +-
drivers/gpu/drm/amd
https://lists.freedesktop.org/archives/amd-gfx/2019-November/042458.html
>
> Regards,
> Evan
>> -Original Message-
>> From: Matt Coffin
>> Sent: Saturday, November 9, 2019 4:50 AM
>> To: Quan, Evan ; amd-gfx@lists.freedesktop.org
>> Cc: Li, Candice ; Gui, Jack ; Ale
Patch is Tested-by: Matt Coffin
On 11/11/19 2:25 AM, Evan Quan wrote:
> Otherwise, without RLC reinitialization, the DPM reenablement
> will fail. That affects the custom pptable uploading.
>
> Change-Id: I6fe2ed5ce23f2a5b66f371c0b6d1f924837e5af6
> Signed-off-by: Evan Quan
>
Hey everyone,
This patch broke variable refresh rate in games (all that I've tried so
far... Project CARS 2, DiRT Rally 2.0, Assetto Corsa Competizione) as
well as a simple freesync tester application.
FreeSync tester I've been using: https://github.com/Nixola/VRRTest
I'm not at all familiar wit
ery single program that mesa allows to utilize
variable refresh rates, and reverting it "fixes" the issue.
Cheers, and sorry for the extra email, just making sure this is still on
someone's radar,
Matt
On 4/14/20 5:32 PM, Matt Coffin wrote:
> Hey everyone,
>
> This patch br
ike to understand more about the setup where this
> is causing issues - ASIC, OS, compositor, displays, dmesg log, X log, etc.
>
> Regards,
> Nicholas Kazlauskas
>
> On 2020-05-05 1:03 p.m., Alex Deucher wrote:
>> Mario or Nick any thoughts?
>>
>> Alex
>>
p.m., Alex Deucher wrote:
>> Mario or Nick any thoughts?
>>
>> Alex
>>
>> On Mon, May 4, 2020 at 1:35 PM Matt Coffin wrote:
>>>
>>> Hey guys,
>>>
>>> This is still an issue for me, and I'm still having to run a patch to
>>
For this, I believe we're updating `table_context->overdrive_table` with
the values set by the user, wouldn't the intended behavior here be to
restore the settings that were there on boot?
If so, I think we'd have to cache the overdrive table that was there on
boot, and use that in the response
On 1/28/20 10:26 AM, Alex Deucher wrote:
> On Tue, Jan 28, 2020 at 11:44 AM Matt Coffin wrote:
> I just copied that vega20 did. You may be right. I haven't paged the
> recent SMU interface stuff into my head in a while. If so, we should
> also fix the vega20_ppt.c code
Let me know if I'm not doing this correctly since I'm still new.
Patch is
Reviewed-by: Matt Coffin
On 1/25/20 11:33 AM, Alex Deucher wrote:
> Doesn't seem to be used, but add it just in case.
>
> Signed-off-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/powe
Previously, the syfs functionality for restoring the default powerplay
table was sourcing it's information from the currently-staged powerplay
table.
This patch adds a step to cache the first overdrive table that we see on
boot, so that it can be used later to "restore" the powerplay table
---
..
powerplay table
Signed-off-by: Matt Coffin
---
.../gpu/drm/amd/powerplay/inc/amdgpu_smu.h| 1 +
drivers/gpu/drm/amd/powerplay/navi10_ppt.c| 9 +++---
drivers/gpu/drm/amd/powerplay/smu_v11_0.c | 6
drivers/gpu/drm/amd/powerplay/vega20_ppt.c| 28 ++-
4 files changed
o that it can be used later to "restore" the powerplay table
>
> v2: sqaush my original with Matt's fix
>
> Bug: https://gitlab.freedesktop.org/drm/amd/issues/1020
> Signed-off-by: Matt Coffin
> Reviewed-by: Alex Deucher
> Signed-off-by: Alex Deucher
>
I was doing some benchmarking, and noticed some poor performance,
indicating that my overdrive settings were not in place, which they
were. hwmon/power1_cap reports the correctly adjusted value after it is
written to, and I confirmed with a quick patch that the updated power
limit value is actually
On 2/6/20 12:55 PM, Alex Deucher wrote:
> Rather than the FEATURE_ID flags. Avoids a possible reading past
> the end of the array.
Just to make sure I understand, this has been broken the whole time,
right, and just happened to be working because we were only using the
lower-end values and happen
downgraded to the first-released microcode as a stop-gap.
On 2/9/20 2:13 PM, Matt Coffin wrote:
> I was doing some benchmarking, and noticed some poor performance,
> indicating that my overdrive settings were not in place, which they
> were. hwmon/power1_cap reports the correctly adjuste
This adds a message lock to the smu_send_smc_msg* implementations to
protect against concurrent access to the mmu registers used to
communicate with the SMU
---
drivers/gpu/drm/amd/powerplay/smu_v11_0.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/dr
ns
since I cannot test.
What do you think of this implementation?
Matt Coffin (2):
drm/amdgpu/powerplay: Refactor SMU message handling for safety
drm/amdgpu/smu: Add message sending lock
drivers/gpu/drm/amd/powerplay/amdgpu_smu.c| 47 +++
drivers/gpu/drm/amd/powerplay/arcturus_pp
Move the responsibility for reading argument registers into the
smu_send_smc_msg* implementations, so that adding a message-sending lock
to protect the SMU registers will result in the lock still being held
when the argument is read.
For code compatibility on hardware I don't have the funds to buy
Hey Alex,
The reason I didn't transition the other code is that I have no hardware
to test with.
I'll go ahead and do it, but someone with the hardware should at least
ensure it boots properly (vega20, and something on smu_v12_0).
With that, I'm good with doing it, I just don't want to risk brea
ff-by: Matt Coffin
---
drivers/gpu/drm/amd/powerplay/amdgpu_smu.c| 46 ++-
drivers/gpu/drm/amd/powerplay/arcturus_ppt.c | 29 +++--
.../gpu/drm/amd/powerplay/inc/amdgpu_smu.h| 2 +-
drivers/gpu/drm/amd/powerplay/inc/smu_v11_0.h | 7 +-
drivers/gpu/drm/amd/powerplay/inc/smu_v1
it's still desired. since smu_send_smc_msg was previously around, and is
used in lots of places, I left it alone rather than replace every
occurance as it still makes sense to be able to safely send messages
without arguments, without knowing that the default argument should be
zero.
Matt
The new interface reads the argument in the call to send the message, so
this is no longer needed, and shouldn't be used for concurrency safety
reasons.
Signed-off-by: Matt Coffin
---
drivers/gpu/drm/amd/powerplay/arcturus_ppt.c | 1 -
drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.
This adds a message lock to the smu_send_smc_msg* implementations to
protect against concurrent access to the mmu registers used to
communicate with the SMU
v2: Implement for smu_v12_0 as well
Signed-off-by: Matt Coffin
---
drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h | 1 +
drivers/gpu/drm
This adds a message lock to the smu_send_smc_msg* implementations to
protect against concurrent access to the mmu registers used to
communicate with the SMU
v2: Implement for smu_v12_0 as well
v3: Add mutex_init for message_lock
Signed-off-by: Matt Coffin
---
drivers/gpu/drm/amd/powerplay
ance as it still makes sense to be able to safely send messages
without arguments, without knowing that the default argument should be
zero.
Matt Coffin (3):
drm/amdgpu/powerplay: Refactor SMU message handling for safety
drm/amdgpu/powerplay: Remove deprecated smc_read_arg
drm/amdgpu/smu: A
The new interface reads the argument in the call to send the message, so
this is no longer needed, and shouldn't be used for concurrency safety
reasons.
Signed-off-by: Matt Coffin
---
drivers/gpu/drm/amd/powerplay/arcturus_ppt.c | 1 -
drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.
ff-by: Matt Coffin
---
drivers/gpu/drm/amd/powerplay/amdgpu_smu.c| 46 ++-
drivers/gpu/drm/amd/powerplay/arcturus_ppt.c | 29 +++--
.../gpu/drm/amd/powerplay/inc/amdgpu_smu.h| 2 +-
drivers/gpu/drm/amd/powerplay/inc/smu_v11_0.h | 7 +-
drivers/gpu/drm/amd/powerplay/inc/smu_v1
On 2/27/20 1:49 PM, Alex Deucher wrote:
> BTW, I think you had another change to clean up some of the navi10
> code, care to send that one out too?
>
> Alex
That was in there just since I was doing some debugging related to
https://gitlab.freedesktop.org/drm/amd/issues/1053 and voltage levels
absence, instead of presence of fan
control capabilities.
Signed-off-by: Matt Coffin
---
drivers/gpu/drm/amd/powerplay/smu_v11_0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/powerplay/smu_v11_0.c
b/drivers/gpu/drm/amd/powerplay/smu_v11_0.c
index
66 matches
Mail list logo
