Re: [PATCH 10/66] drm/amd/display: Do not set drr on pipe commit

[Michel Dänzer]

On 6/12/23 20:14, Pillai, Aurabindo wrote:
> 
> I want to double check if we're identifying the correct monitor for applying 
> the workaround. Could you please try the attached patch and let me know the 
> panel id ?

 amdgpu: ### Not applying any edid quirk for panel 4c2d71ac

I'm attaching the EDID.

BTW, I'm using the monitor firmware version 1011.0, which AFAICT is the latest.


-- 
Earthling Michel Dänzer|  https://redhat.com
Libre software enthusiast  | Mesa and Xwayland developer



edid
Description: Binary data

Re: [PATCH 10/66] drm/amd/display: Do not set drr on pipe commit

[Pillai, Aurabindo]

[Public]

Hi Michel,

I want to double check if we're identifying the correct monitor for applying 
the workaround. Could you please try the attached patch and let me know the 
panel id ?

--

Regards,
Jay

From: Michel Dänzer 
Sent: Thursday, June 8, 2023 11:18 AM
To: Pillai, Aurabindo ; Zhuo, Qingqing (Lillian) 
; Chalmers, Wesley 
Cc: Wang, Chao-kai (Stylon) ; Li, Sun peng (Leo) 
; Wentland, Harry ; Siqueira, 
Rodrigo ; Li, Roman ; 
amd-gfx@lists.freedesktop.org ; Chiu, Solomon 
; Lin, Wayne ; Lakha, Bhawanpreet 
; Gutierrez, Agustin ; 
Kotarac, Pavle 
Subject: Re: [PATCH 10/66] drm/amd/display: Do not set drr on pipe commit

On 6/8/23 16:31, Pillai, Aurabindo wrote:
>
> Thanks Michel,
>
> I reached out to windows driver team, and they have a monitor specific quirk 
> to disable FAMS on this model. I suspect the issue is only present on certain 
> fw revisions on the monitor which is why we cant see your issue.
>
> Unfortunately, having the patches in question reverted causes hangs with 3 
> monitor setups. So I will push that monitor specific quirk and bring back the 
> reverted patches.

Sounds good, thanks.


--
Earthling Michel Dänzer|  https://redhat.com
Libre software enthusiast  | Mesa and Xwayland developer

From 3dfcb5e60ec9fc9ec6c573231e5b6aa4edca2ed6 Mon Sep 17 00:00:00 2001
From: Aurabindo Pillai 
Date: Mon, 12 Jun 2023 12:44:00 -0400
Subject: [PATCH] drm/amd/display: Add monitor specific edid quirk

Disable FAMS on a Samsung Odyssey G9 monitor. Experiments show that this
monitor does not work well under some use cases, and is likely
implementation specific bug on some revisions of the device.

Signed-off-by: Aurabindo Pillai 
---
 .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 24 +++
 1 file changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index cd20cfc04996..e7e545665007 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -44,6 +44,28 @@
 #include "dm_helpers.h"
 #include "ddc_service_types.h"
 
+static u32 edid_extract_panel_id(struct edid *edid)
+{
+	return (u32)edid->mfg_id[0] << 24   |
+	   (u32)edid->mfg_id[1] << 16   |
+	   (u32)EDID_PRODUCT_ID(edid);
+}
+
+static void apply_edid_quirks(struct edid *edid, struct dc_edid_caps *edid_caps) {
+	uint32_t panel_id = edid_extract_panel_id(edid);
+
+	switch (panel_id) {
+	case drm_edid_encode_panel_id('S', 'A', 'M', 0x0E5E):
+	case drm_edid_encode_panel_id('S', 'A', 'M', 0x7053):
+		pr_err("### Applying any edid quirk for panel %x\n", panel_id);
+		edid_caps->panel_patch.disable_fams = true;
+		break;
+	default:
+		pr_err("### Not applying any edid quirk for panel %x\n", panel_id);
+		return;
+	}
+}
+
 /* dm_helpers_parse_edid_caps
  *
  * Parse edid caps
@@ -115,6 +137,8 @@ enum dc_edid_status dm_helpers_parse_edid_caps(
 	else
 		edid_caps->speaker_flags = DEFAULT_SPEAKER_LOCATION;
 
+	apply_edid_quirks(edid_buf, edid_caps);
+
 	kfree(sads);
 	kfree(sadb);
 
-- 
2.40.1

Re: [PATCH 10/66] drm/amd/display: Do not set drr on pipe commit

[Michel Dänzer]

On 6/8/23 16:31, Pillai, Aurabindo wrote:
> 
> Thanks Michel,
> 
> I reached out to windows driver team, and they have a monitor specific quirk 
> to disable FAMS on this model. I suspect the issue is only present on certain 
> fw revisions on the monitor which is why we cant see your issue.
> 
> Unfortunately, having the patches in question reverted causes hangs with 3 
> monitor setups. So I will push that monitor specific quirk and bring back the 
> reverted patches.

Sounds good, thanks.


-- 
Earthling Michel Dänzer|  https://redhat.com
Libre software enthusiast  | Mesa and Xwayland developer

Re: [PATCH 10/66] drm/amd/display: Do not set drr on pipe commit

[Pillai, Aurabindo]

[Public]

Thanks Michel,

I reached out to windows driver team, and they have a monitor specific quirk to 
disable FAMS on this model. I suspect the issue is only present on certain fw 
revisions on the monitor which is why we cant see your issue.

Unfortunately, having the patches in question reverted causes hangs with 3 
monitor setups. So I will push that monitor specific quirk and bring back the 
reverted patches.

--

Regards,
Jay

From: Michel Dänzer 
Sent: Thursday, June 8, 2023 10:20 AM
To: Pillai, Aurabindo ; Zhuo, Qingqing (Lillian) 
; Chalmers, Wesley 
Cc: Wang, Chao-kai (Stylon) ; Li, Sun peng (Leo) 
; Lakha, Bhawanpreet ; Siqueira, 
Rodrigo ; Li, Roman ; 
amd-gfx@lists.freedesktop.org ; Chiu, Solomon 
; Lin, Wayne ; Wentland, Harry 
; Gutierrez, Agustin ; 
Kotarac, Pavle 
Subject: Re: [PATCH 10/66] drm/amd/display: Do not set drr on pipe commit

On 6/7/23 19:35, Pillai, Aurabindo wrote:
>
> Do you see the issue if you force disable FAMS?
Neither hang occurs with FAMS disabled.


--
Earthling Michel Dänzer|  https://redhat.com
Libre software enthusiast  | Mesa and Xwayland developer

Re: [PATCH 10/66] drm/amd/display: Do not set drr on pipe commit

[Michel Dänzer]

On 6/7/23 19:35, Pillai, Aurabindo wrote:
> 
> Do you see the issue if you force disable FAMS?
Neither hang occurs with FAMS disabled.


-- 
Earthling Michel Dänzer|  https://redhat.com
Libre software enthusiast  | Mesa and Xwayland developer

Re: [PATCH 10/66] drm/amd/display: Do not set drr on pipe commit

[Pillai, Aurabindo]

[Public]

Thanks Michel.

Do you see the issue if you force disable FAMS?  The following diff should do:

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 f4ee4b3df596..475c16aab518 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_resource.c
@@ -725,7 +725,8 @@ static const struct dc_debug_options debug_defaults_drv = {
.dwb_fi_phase = -1, // -1 = disable,
.dmub_command_table = true,
.use_max_lb = true,
-   .exit_idle_opt_for_cursor_updates = true
+   .exit_idle_opt_for_cursor_updates = true,
+   .disable_fams=true
 };

 static const struct dc_panel_config panel_config_defaults = {


--

Regards,
Jay

From: Michel Dänzer 
Sent: Wednesday, June 7, 2023 1:00 PM
To: Pillai, Aurabindo ; Zhuo, Qingqing (Lillian) 
; Chalmers, Wesley 
Cc: Wang, Chao-kai (Stylon) ; Li, Sun peng (Leo) 
; Wentland, Harry ; Siqueira, 
Rodrigo ; Li, Roman ; Chiu, Solomon 
; Lin, Wayne ; Lakha, Bhawanpreet 
; Gutierrez, Agustin ; 
Kotarac, Pavle ; amd-gfx@lists.freedesktop.org 

Subject: Re: [PATCH 10/66] drm/amd/display: Do not set drr on pipe commit

On 6/6/23 20:01, Pillai, Aurabindo wrote:
>
> I'm attaching another DMCUB firmware which has the bug fix for the hang we 
> saw at our end and some added tracing enabled.

Still runs into the newer hang when starting a KDE Plasma Wayland session.

Should I try this for starting the game without the program OTG patch as well?


> Could you please grab the dmesg with the following added to the kernel 
> cmdline: "drm.debug=0x156 log_buf_len=20M" using stock gnome/kde when you 
> have all 3 patches merged ?
>
> Also attach the contents of /sys/kernel/debug/dri/0/amdgpu_dm_dmub_tracebuffer

Both files attached.


--
Earthling Michel Dänzer|  https://redhat.com
Libre software enthusiast  | Mesa and Xwayland developer

Re: [PATCH 10/66] drm/amd/display: Do not set drr on pipe commit

[Michel Dänzer]

On 6/6/23 20:01, Pillai, Aurabindo wrote:
> 
> I'm attaching another DMCUB firmware which has the bug fix for the hang we 
> saw at our end and some added tracing enabled.

Still runs into the newer hang when starting a KDE Plasma Wayland session.

Should I try this for starting the game without the program OTG patch as well?


> Could you please grab the dmesg with the following added to the kernel 
> cmdline: "drm.debug=0x156 log_buf_len=20M" using stock gnome/kde when you 
> have all 3 patches merged ?
> 
> Also attach the contents of /sys/kernel/debug/dri/0/amdgpu_dm_dmub_tracebuffer

Both files attached.


-- 
Earthling Michel Dänzer|  https://redhat.com
Libre software enthusiast  | Mesa and Xwayland developer

trace_code=14 tick_count=803999866 param0=278 param1=385593
trace_code=1 tick_count=3671977301 param0=10 param1=0
trace_code=1 tick_count=3671977329 param0=10 param1=1
trace_code=1 tick_count=3671977641 param0=10 param1=3
trace_code=1 tick_count=3671977821 param0=10 param1=4
trace_code=252 tick_count=3671978129 param0=1844 param1=2
trace_code=1 tick_count=3671978793 param0=10 param1=1
trace_code=1 tick_count=3671978825 param0=10 param1=1
trace_code=1 tick_count=3671978857 param0=10 param1=1
trace_code=1 tick_count=3671978885 param0=10 param1=1
trace_code=1 tick_count=3671978917 param0=10 param1=1
trace_code=248 tick_count=3671979201 param0=39399 param1=1454
trace_code=1 tick_count=3671979237 param0=15 param1=1
trace_code=1 tick_count=3671979265 param0=9 param1=0
trace_code=1 tick_count=3671979293 param0=11 param1=1
trace_code=1 tick_count=3671979325 param0=11 param1=2
trace_code=1 tick_count=3672322941 param0=14 param1=0
trace_code=1 tick_count=3672322973 param0=14 param1=4
trace_code=1 tick_count=3672323705 param0=13 param1=4
trace_code=1 tick_count=3672324361 param0=14 param1=0
trace_code=1 tick_count=3672324397 param0=14 param1=1
trace_code=1 tick_count=3672324437 param0=14 param1=2
trace_code=250 tick_count=3672324497 param0=39399 param1=1454
trace_code=1 tick_count=3672355113 param0=14 param1=4
trace_code=1 tick_count=3672355353 param0=13 param1=1
trace_code=249 tick_count=3672362293 param0=39399 param1=1454
trace_code=1 tick_count=3672362325 param0=15 param1=1
trace_code=251 tick_count=3672362389 param0=39399 param1=1454
trace_code=1 tick_count=3672362541 param0=12 param1=2
trace_code=1 tick_count=3672362809 param0=12 param1=3
trace_code=1 tick_count=3672362845 param0=12 param1=3
trace_code=1 tick_count=3672362877 param0=12 param1=3
trace_code=1 tick_count=3672362909 param0=12 param1=3
trace_code=1 tick_count=3672362941 param0=12 param1=3
trace_code=249 tick_count=3672363241 param0=39399 param1=1454
trace_code=1 tick_count=3672363273 param0=15 param1=1
trace_code=1 tick_count=3672363305 param0=12 param1=1
trace_code=1 tick_count=3672434629 param0=14 param1=0
trace_code=1 tick_count=3672434657 param0=14 param1=4
trace_code=1 tick_count=3672434897 param0=13 param1=3
trace_code=252 tick_count=3672435049 param0=0 param1=3
trace_code=248 tick_count=3672958573 param0=39817 param1=1454
trace_code=1 tick_count=3672958605 param0=15 param1=1
trace_code=1 tick_count=3672958637 param0=9 param1=0
trace_code=1 tick_count=3672958665 param0=11 param1=1
trace_code=1 tick_count=3672958981 param0=11 param1=4
trace_code=1 tick_count=3672959013 param0=10 param1=0
trace_code=1 tick_count=3672959041 param0=10 param1=1
trace_code=1 tick_count=3672959141 param0=10 param1=3
trace_code=1 tick_count=3672959229 param0=10 param1=4
trace_code=252 tick_count=3672959273 param0=1844 param1=2
trace_code=1 tick_count=3672959461 param0=10 param1=1
trace_code=1 tick_count=3672959493 param0=10 param1=1
trace_code=1 tick_count=3672959529 param0=10 param1=1
trace_code=1 tick_count=3672959557 param0=10 param1=1
trace_code=1 tick_count=3672959589 param0=10 param1=1
trace_code=248 tick_count=3672959973 param0=39822 param1=1454
trace_code=1 tick_count=3672960005 param0=15 param1=1
trace_code=1 tick_count=3672960033 param0=9 param1=0
trace_code=1 tick_count=3672960061 param0=11 param1=1
trace_code=1 tick_count=3672960089 param0=11 param1=2
trace_code=0 tick_count=0 param0=0 param1=0
trace_code=0 tick_count=0 param0=0 param1=0
trace_code=0 tick_count=0 param0=0 param1=0
trace_code=0 tick_count=0 param0=0 param1=0
trace_code=0 tick_count=0 param0=0 param1=0
trace_code=0 tick_count=0 param0=0 param1=0


dmesg-amdgpu-dc-hang.txt.gz
Description: application/gzip

Re: [PATCH 10/66] drm/amd/display: Do not set drr on pipe commit

[Michel Dänzer]

On 6/2/23 19:13, Pillai, Aurabindo wrote:
> 
> AMD driver package also contains various firmware that could make a 
> difference.

I tried the firmware from 
amdgpu-dkms-firmware_1%3a5.18.13.50405-1577590.20.04_all.deb, it didn't help 
for either hang.

I also tried the firmware from current linux-firmware Git, didn't help either.


> We tried upstream stack (without any AMD packaged driver) on Ubuntu 22.04 on 
> the same display that you reported the issue on, but couldn't reproduce the 
> hang you're seeing (using a different steam game that uses the same 
> framework). Maybe your custom gnome build could have affected the results too.

I've been able to reproduce both hangs with a stock KDE Plasma 5.27 Wayland 
session as well. The older hang when starting the game can be avoided by 
disabling VRR in the KDE Plasma display settings, the newer hang with the 
program OTG patch cannot.

I've been able to reproduce both hangs with a GNOME X11 session as well. So my 
custom mutter build doesn't affect the results.


> Other than the game, is there any other workload that could trigger the hang?

With the program OTG patch, just logging into a GNOME or KDE Plasma session 
does it (I previously thought it happened only when Steam Big Picture starts 
up, but then I noticed I couldn't see my GNOME session at all). Disabling 
FreeSync in the monitor's OSD menu avoids this hang.


FWIW, I've verified that neither hang occurs with only the program OTG patch 
applied and the other two patches reverted.


> We have a set of IGT tests you could try:

Results attached. This is with all 3 problematic patches applied and FreeSync 
enabled in the monitor's OSD settings.


-- 
Earthling Michel Dänzer|  https://redhat.com
Libre software enthusiast  | Mesa and Xwayland developer


igt-gpu-tools-results.tar.xz
Description: application/xz

Re: [PATCH 10/66] drm/amd/display: Do not set drr on pipe commit

[Pillai, Aurabindo]

[Public]

Hi Michel,

AMD driver package also contains various firmware that could make a difference. 
Even though I do not expect any major deltas for Navi21 at this point, its an 
extra variable in the equation that could potentially create a different 
behaviour.

We tried upstream stack (without any AMD packaged driver) on Ubuntu 22.04 on 
the same display that you reported the issue on, but couldn't reproduce the 
hang you're seeing (using a different steam game that uses the same framework). 
Maybe your custom gnome build could have affected the results too. Could you 
provide instructions for setting up your userspace environment ?

Other than the game, is there any other workload that could trigger the hang? 
We have a set of IGT tests you could try:

Repo: https://gitlab.freedesktop.org/drm/igt-gpu-tools

Build & install:

meson build

# Compile IGT
ninja -C build

# Download Piglit
./scripts/run-tests.sh -d

Run tests
./scripts/run-tests.sh -s -T /path/to/navi21_postsubmission.testlist


--

Regards,
Jay

From: Michel Dänzer 
Sent: Thursday, June 1, 2023 11:53 AM
To: Pillai, Aurabindo ; Zhuo, Qingqing (Lillian) 
; amd-gfx@lists.freedesktop.org 
; Chalmers, Wesley 
Cc: Wang, Chao-kai (Stylon) ; Li, Sun peng (Leo) 
; Lakha, Bhawanpreet ; Siqueira, 
Rodrigo ; Li, Roman ; Chiu, Solomon 
; Lin, Wayne ; Wentland, Harry 
; Gutierrez, Agustin ; 
Kotarac, Pavle 
Subject: Re: [PATCH 10/66] drm/amd/display: Do not set drr on pipe commit

On 6/1/23 17:45, Pillai, Aurabindo wrote:
>
> I see, thanks for the info. I'll try repro'ing it locally.

Thanks. Note that I'm using a GNOME Wayland session, which doesn't support VRR 
upstream yet (I'm building mutter with 
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1154 for that). I don't 
know if it's reproducible with Xorg.


> But do you have the open userspace stack from AMD's packaged driver installed 
> ? If not, could you please try downloading from 
> https://www.amd.com/en/support/linux-drivers 
> <https://www.amd.com/en/support/linux-drivers> and install just the open 
> components?

I don't, and I'd rather not unless it's absolutely necessary. I'm not sure how 
the user-space drivers could affect this.

I'll happily test further patches though.


--
Earthling Michel Dänzer|  https://redhat.com
Libre software enthusiast  | Mesa and Xwayland developer



navi21_postsubmission.testlist
Description: navi21_postsubmission.testlist

Re: [PATCH 10/66] drm/amd/display: Do not set drr on pipe commit

[Michel Dänzer]

On 6/1/23 17:45, Pillai, Aurabindo wrote:
> 
> I see, thanks for the info. I'll try repro'ing it locally.

Thanks. Note that I'm using a GNOME Wayland session, which doesn't support VRR 
upstream yet (I'm building mutter with 
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1154 for that). I don't 
know if it's reproducible with Xorg.


> But do you have the open userspace stack from AMD's packaged driver installed 
> ? If not, could you please try downloading from 
> https://www.amd.com/en/support/linux-drivers 
>  and install just the open 
> components?

I don't, and I'd rather not unless it's absolutely necessary. I'm not sure how 
the user-space drivers could affect this.

I'll happily test further patches though.


-- 
Earthling Michel Dänzer|  https://redhat.com
Libre software enthusiast  | Mesa and Xwayland developer

Re: [PATCH 10/66] drm/amd/display: Do not set drr on pipe commit

[Pillai, Aurabindo]

[Public]

I see, thanks for the info. I'll try repro'ing it locally. But do you have the 
open userspace stack from AMD's packaged driver installed ? If not, could you 
please try downloading from https://www.amd.com/en/support/linux-drivers and 
install just the open components? You can run:

sudo amdgpu-install --use-case=graphics --no-dkms


--

Regards,
Jay

From: amd-gfx  on behalf of Michel 
Dänzer 
Sent: Thursday, June 1, 2023 10:59 AM
To: Pillai, Aurabindo ; Zhuo, Qingqing (Lillian) 
; amd-gfx@lists.freedesktop.org 
; Chalmers, Wesley 
Cc: Wang, Chao-kai (Stylon) ; Li, Sun peng (Leo) 
; Wentland, Harry ; Siqueira, 
Rodrigo ; Li, Roman ; Chiu, Solomon 
; Lin, Wayne ; Lakha, Bhawanpreet 
; Gutierrez, Agustin ; 
Kotarac, Pavle 
Subject: Re: [PATCH 10/66] drm/amd/display: Do not set drr on pipe commit

On 5/31/23 22:14, Aurabindo Pillai wrote:
> On 5/11/23 03:06, Michel Dänzer wrote:
>> On 5/10/23 22:54, Aurabindo Pillai wrote:
>>> On 5/10/23 09:20, Michel Dänzer wrote:
>>>> On 5/9/23 23:07, Pillai, Aurabindo wrote:
>>>>>
>>>>> Sorry - the firmware in the previous message is for DCN32. For Navi2x, 
>>>>> please use the firmware attached here.
>>>>
>>>> Same problem (contents of /sys/kernel/debug/dri/0/amdgpu_firmware_info 
>>>> below).
>>>>
>>>> Even if it did work with newer FW, the kernel must keep working with older 
>>>> FW, so in that case the new behaviour would need to be guarded by the FW 
>>>> version.
>>>>
>>>
>>> Agreed. Were you able to repro the hang on any other modes/monitors?
>>
>> Haven't tried specifically, and this is the only system I have with VRR.
>>
>>
> Hi Michel,
>
> I've fixed a related issue on Navi21. Could you please try the attached DMCUB 
> along with the patches to be applied on top of amd-staging-drm-next and check 
> if the hang/corruption is gone?

Thanks, though I'm afraid that made it kind of worse: Now it already hangs when 
Steam starts up in Big Picture mode. Same with the new DMCUB firmware or older 
one.

This time, only

 amdgpu :0c:00.0: [drm] *ERROR* [CRTC:82:crtc-0] flip_done timed out

appears in dmesg.


--
Earthling Michel Dänzer|  https://redhat.com
Libre software enthusiast  | Mesa and Xwayland developer

Re: [PATCH 10/66] drm/amd/display: Do not set drr on pipe commit

[Michel Dänzer]

On 5/31/23 22:14, Aurabindo Pillai wrote:
> On 5/11/23 03:06, Michel Dänzer wrote:
>> On 5/10/23 22:54, Aurabindo Pillai wrote:
>>> On 5/10/23 09:20, Michel Dänzer wrote:
 On 5/9/23 23:07, Pillai, Aurabindo wrote:
>
> Sorry - the firmware in the previous message is for DCN32. For Navi2x, 
> please use the firmware attached here.

 Same problem (contents of /sys/kernel/debug/dri/0/amdgpu_firmware_info 
 below).

 Even if it did work with newer FW, the kernel must keep working with older 
 FW, so in that case the new behaviour would need to be guarded by the FW 
 version.

>>>
>>> Agreed. Were you able to repro the hang on any other modes/monitors? 
>>
>> Haven't tried specifically, and this is the only system I have with VRR.
>>
>>
> Hi Michel,
> 
> I've fixed a related issue on Navi21. Could you please try the attached DMCUB 
> along with the patches to be applied on top of amd-staging-drm-next and check 
> if the hang/corruption is gone? 

Thanks, though I'm afraid that made it kind of worse: Now it already hangs when 
Steam starts up in Big Picture mode. Same with the new DMCUB firmware or older 
one.

This time, only

 amdgpu :0c:00.0: [drm] *ERROR* [CRTC:82:crtc-0] flip_done timed out

appears in dmesg.


-- 
Earthling Michel Dänzer|  https://redhat.com
Libre software enthusiast  | Mesa and Xwayland developer

Re: [PATCH 10/66] drm/amd/display: Do not set drr on pipe commit

[Michel Dänzer]

On 5/10/23 22:54, Aurabindo Pillai wrote:
> On 5/10/23 09:20, Michel Dänzer wrote:
>> On 5/9/23 23:07, Pillai, Aurabindo wrote:
>>>
>>> Sorry - the firmware in the previous message is for DCN32. For Navi2x, 
>>> please use the firmware attached here.
>>
>> Same problem (contents of /sys/kernel/debug/dri/0/amdgpu_firmware_info 
>> below).
>>
>> Even if it did work with newer FW, the kernel must keep working with older 
>> FW, so in that case the new behaviour would need to be guarded by the FW 
>> version.
>>
> 
> Agreed. Were you able to repro the hang on any other modes/monitors? 

Haven't tried specifically, and this is the only system I have with VRR.


-- 
Earthling Michel Dänzer|  https://redhat.com
Libre software enthusiast  | Mesa and Xwayland developer

Re: [PATCH 10/66] drm/amd/display: Do not set drr on pipe commit

[Aurabindo Pillai]

On 5/10/23 09:20, Michel Dänzer wrote:
> On 5/9/23 23:07, Pillai, Aurabindo wrote:
>>
>> Sorry - the firmware in the previous message is for DCN32. For Navi2x, 
>> please use the firmware attached here.
> 
> Same problem (contents of /sys/kernel/debug/dri/0/amdgpu_firmware_info below).
> 
> Even if it did work with newer FW, the kernel must keep working with older 
> FW, so in that case the new behaviour would need to be guarded by the FW 
> version.
> 

Agreed. Were you able to repro the hang on any other modes/monitors? 

> 
> VCE feature version: 0, firmware version: 0x
> UVD feature version: 0, firmware version: 0x
> MC feature version: 0, firmware version: 0x
> ME feature version: 44, firmware version: 0x0040
> PFP feature version: 44, firmware version: 0x0061
> CE feature version: 44, firmware version: 0x0025
> RLC feature version: 1, firmware version: 0x0060
> RLC SRLC feature version: 0, firmware version: 0x
> RLC SRLG feature version: 0, firmware version: 0x
> RLC SRLS feature version: 0, firmware version: 0x
> RLCP feature version: 0, firmware version: 0x
> RLCV feature version: 0, firmware version: 0x
> MEC feature version: 44, firmware version: 0x0071
> MEC2 feature version: 44, firmware version: 0x0071
> IMU feature version: 0, firmware version: 0x
> SOS feature version: 0, firmware version: 0x00210c64
> ASD feature version: 553648297, firmware version: 0x21a9
> TA XGMI feature version: 0x, firmware version: 0x200f
> TA RAS feature version: 0x, firmware version: 0x1b00013e
> TA HDCP feature version: 0x, firmware version: 0x1738
> TA DTM feature version: 0x, firmware version: 0x1215
> TA RAP feature version: 0x, firmware version: 0x07000213
> TA SECUREDISPLAY feature version: 0x, firmware version: 0x
> SMC feature version: 0, program: 0, firmware version: 0x003a5800 (58.88.0)
> SDMA0 feature version: 52, firmware version: 0x0053
> SDMA1 feature version: 52, firmware version: 0x0053
> SDMA2 feature version: 52, firmware version: 0x0053
> SDMA3 feature version: 52, firmware version: 0x0053
> VCN feature version: 0, firmware version: 0x0211b000
> DMCU feature version: 0, firmware version: 0x
> DMCUB feature version: 0, firmware version: 0x0202001c
> TOC feature version: 0, firmware version: 0x
> MES_KIQ feature version: 0, firmware version: 0x
> MES feature version: 0, firmware version: 0x
> VBIOS version: 113-D4300100-051
> 
> 
> --
>> *From:* Pillai, Aurabindo 
>> *Sent:* Tuesday, May 9, 2023 4:44 PM
>> *To:* Michel Dänzer ; Zhuo, Qingqing (Lillian) 
>> ; amd-gfx@lists.freedesktop.org 
>> ; Chalmers, Wesley 
>> *Cc:* Wang, Chao-kai (Stylon) ; Li, Sun peng (Leo) 
>> ; Wentland, Harry ; Siqueira, 
>> Rodrigo ; Li, Roman ; Chiu, 
>> Solomon ; Lin, Wayne ; Lakha, 
>> Bhawanpreet ; Gutierrez, Agustin 
>> ; Kotarac, Pavle 
>> *Subject:* Re: [PATCH 10/66] drm/amd/display: Do not set drr on pipe commit
>>  
>> Hi Michel,
>>
>> Could you please try with the attached firmware package if you see the hang 
>> without any reverts?  If you do see hangs, please send dmesg with 
>> "drm.debug=0x156 log_buf_len=30M" in the kernel cmdline.
>>
>> The attached fw is not released to the public yet, but we will be updating 
>&

Re: [PATCH 10/66] drm/amd/display: Do not set drr on pipe commit

[Michel Dänzer]

On 5/9/23 23:07, Pillai, Aurabindo wrote:
> 
> Sorry - the firmware in the previous message is for DCN32. For Navi2x, please 
> use the firmware attached here.

Same problem (contents of /sys/kernel/debug/dri/0/amdgpu_firmware_info below).

Even if it did work with newer FW, the kernel must keep working with older FW, 
so in that case the new behaviour would need to be guarded by the FW version.


VCE feature version: 0, firmware version: 0x
UVD feature version: 0, firmware version: 0x
MC feature version: 0, firmware version: 0x
ME feature version: 44, firmware version: 0x0040
PFP feature version: 44, firmware version: 0x0061
CE feature version: 44, firmware version: 0x0025
RLC feature version: 1, firmware version: 0x0060
RLC SRLC feature version: 0, firmware version: 0x
RLC SRLG feature version: 0, firmware version: 0x
RLC SRLS feature version: 0, firmware version: 0x
RLCP feature version: 0, firmware version: 0x
RLCV feature version: 0, firmware version: 0x
MEC feature version: 44, firmware version: 0x0071
MEC2 feature version: 44, firmware version: 0x0071
IMU feature version: 0, firmware version: 0x
SOS feature version: 0, firmware version: 0x00210c64
ASD feature version: 553648297, firmware version: 0x21a9
TA XGMI feature version: 0x, firmware version: 0x200f
TA RAS feature version: 0x, firmware version: 0x1b00013e
TA HDCP feature version: 0x, firmware version: 0x1738
TA DTM feature version: 0x, firmware version: 0x1215
TA RAP feature version: 0x, firmware version: 0x07000213
TA SECUREDISPLAY feature version: 0x, firmware version: 0x
SMC feature version: 0, program: 0, firmware version: 0x003a5800 (58.88.0)
SDMA0 feature version: 52, firmware version: 0x0053
SDMA1 feature version: 52, firmware version: 0x0053
SDMA2 feature version: 52, firmware version: 0x0053
SDMA3 feature version: 52, firmware version: 0x0053
VCN feature version: 0, firmware version: 0x0211b000
DMCU feature version: 0, firmware version: 0x
DMCUB feature version: 0, firmware version: 0x0202001c
TOC feature version: 0, firmware version: 0x
MES_KIQ feature version: 0, firmware version: 0x
MES feature version: 0, firmware version: 0x
VBIOS version: 113-D4300100-051


--
> *From:* Pillai, Aurabindo 
> *Sent:* Tuesday, May 9, 2023 4:44 PM
> *To:* Michel Dänzer ; Zhuo, Qingqing (Lillian) 
> ; amd-gfx@lists.freedesktop.org 
> ; Chalmers, Wesley 
> *Cc:* Wang, Chao-kai (Stylon) ; Li, Sun peng (Leo) 
> ; Wentland, Harry ; Siqueira, 
> Rodrigo ; Li, Roman ; Chiu, 
> Solomon ; Lin, Wayne ; Lakha, 
> Bhawanpreet ; Gutierrez, Agustin 
> ; Kotarac, Pavle 
> *Subject:* Re: [PATCH 10/66] drm/amd/display: Do not set drr on pipe commit
>  
> Hi Michel,
> 
> Could you please try with the attached firmware package if you see the hang 
> without any reverts?  If you do see hangs, please send dmesg with 
> "drm.debug=0x156 log_buf_len=30M" in the kernel cmdline.
> 
> The attached fw is not released to the public yet, but we will be updating 
> them in linux-firmware tree next week. Please do backup your existing 
> firmware, and put the attached files into /usr/lib/firmware/updates/amgpu and 
> regenerate your ramdisk. On ubuntu the foll

Re: [PATCH 10/66] drm/amd/display: Do not set drr on pipe commit

[Michel Dänzer]

On 4/14/23 17:52, Qingqing Zhuo wrote:
> From: Wesley Chalmers 
> 
> [WHY]
> Writing to DRR registers such as OTG_V_TOTAL_MIN on the same frame as a
> pipe commit can cause underflow.
> 
> [HOW]
> Move DMUB p-state delegate into optimze_bandwidth; enabling FAMS sets
> optimized_required.
> 
> This change expects that Freesync requests are blocked when
> optimized_required is true.
> 
> Reviewed-by: Rodrigo Siqueira 
> Signed-off-by: Wesley Chalmers 
I bisected a regression to this change, see below for the symptoms. Reverting 
this patch (and the following patch "drm/amd/display: Block optimize on 
consecutive FAMS enables", which depends on it) on top of the DRM changes 
merged for 6.4-rc1 avoids the regression.

Maybe "Freesync requests are blocked when optimized_required is true" isn't 
ensured as needed?


The symptoms are that the monitor (Samsung Odyssey Neo G9, 5120x1440@240/VRR, 
connected to Navi 21 via DisplayPort) blanks and the GPU hangs while starting 
the Steam game Assetto Corsa Competizione (via Proton 7.0).

Example dmesg excerpt:

 amdgpu :0c:00.0: [drm] *ERROR* [CRTC:82:crtc-0] flip_done timed out
 NMI watchdog: Watchdog detected hard LOCKUP on cpu 6
 [...]
 RIP: 0010:amdgpu_device_rreg.part.0+0x2f/0xf0 [amdgpu]
 Code: 41 54 44 8d 24 b5 00 00 00 00 55 89 f5 53 48 89 fb 4c 3b a7 60 0b 00 00 
73 6a 83 e2 02 74 29 4c 03 a3 68 0b 00 00 45 8b 24 24 <48> 8b 43 08 0f b7 70 3e 
66 90 44 89 e0 5b 5d 41 5c 31 d2 31 c9 31
 RSP: :b39a119dfb88 EFLAGS: 0086
 RAX: c0eb96a0 RBX: 9e7963dc RCX: 7fff
 RDX:  RSI: 4ff6 RDI: 9e7963dc
 RBP: 4ff6 R08: b39a119dfc40 R09: 0010
 R10: b39a119dfc40 R11: b39a119dfc44 R12: 000e05ae
 R13:  R14: 9e7963dc0010 R15: 
 FS:  1012f6c0() GS:9e805eb8() knlGS:7fd4
 CS:  0010 DS:  ES:  CR0: 80050033
 CR2: 461ca000 CR3: 0002a8a2 CR4: 00350ee0
 Call Trace:
  
  dm_read_reg_func+0x37/0xc0 [amdgpu]
  generic_reg_get2+0x22/0x60 [amdgpu]
  optc1_get_crtc_scanoutpos+0x6a/0xc0 [amdgpu]
  dc_stream_get_scanoutpos+0x74/0x90 [amdgpu]
  dm_crtc_get_scanoutpos+0x82/0xf0 [amdgpu]
  amdgpu_display_get_crtc_scanoutpos+0x91/0x190 [amdgpu]
  ? dm_read_reg_func+0x37/0xc0 [amdgpu]
  amdgpu_get_vblank_counter_kms+0xb4/0x1a0 [amdgpu]
  dm_pflip_high_irq+0x213/0x2f0 [amdgpu]
  amdgpu_dm_irq_handler+0x8a/0x200 [amdgpu]
  amdgpu_irq_dispatch+0xd4/0x220 [amdgpu]
  amdgpu_ih_process+0x7f/0x110 [amdgpu]
  amdgpu_irq_handler+0x1f/0x70 [amdgpu]
  __handle_irq_event_percpu+0x46/0x1b0
  handle_irq_event+0x34/0x80
  handle_edge_irq+0x9f/0x240
  __common_interrupt+0x66/0x110
  common_interrupt+0x5c/0xd0
  asm_common_interrupt+0x22/0x40


-- 
Earthling Michel Dänzer|  https://redhat.com
Libre software enthusiast  | Mesa and Xwayland developer

[PATCH 10/66] drm/amd/display: Do not set drr on pipe commit

[Qingqing Zhuo]

From: Wesley Chalmers 

[WHY]
Writing to DRR registers such as OTG_V_TOTAL_MIN on the same frame as a
pipe commit can cause underflow.

[HOW]
Move DMUB p-state delegate into optimze_bandwidth; enabling FAMS sets
optimized_required.

This change expects that Freesync requests are blocked when
optimized_required is true.

Reviewed-by: Rodrigo Siqueira 
Signed-off-by: Wesley Chalmers 
---
 drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c | 6 ++
 drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c | 7 +++
 2 files changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c 
b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c
index 5403e9399a46..6ce10fd4bb1a 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c
@@ -2113,6 +2113,12 @@ void dcn20_optimize_bandwidth(
if (hubbub->funcs->program_compbuf_size)
hubbub->funcs->program_compbuf_size(hubbub, 
context->bw_ctx.bw.dcn.compbuf_size_kb, true);
 
+   if (context->bw_ctx.bw.dcn.clk.fw_based_mclk_switching) {
+   dc_dmub_srv_p_state_delegate(dc,
+   true, context);
+   context->bw_ctx.bw.dcn.clk.p_state_change_support = true;
+   }
+
dc->clk_mgr->funcs->update_clocks(
dc->clk_mgr,
context,
diff --git a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c 
b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c
index 0e071fbc9154..0411867654dd 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c
@@ -985,11 +985,18 @@ void dcn30_set_disp_pattern_generator(const struct dc *dc,
 void dcn30_prepare_bandwidth(struct dc *dc,
struct dc_state *context)
 {
+   if (context->bw_ctx.bw.dcn.clk.fw_based_mclk_switching) {
+   dc->optimized_required = true;
+   context->bw_ctx.bw.dcn.clk.p_state_change_support = false;
+   }
+
if (dc->clk_mgr->dc_mode_softmax_enabled)
if (dc->clk_mgr->clks.dramclk_khz <= 
dc->clk_mgr->bw_params->dc_mode_softmax_memclk * 1000 &&
context->bw_ctx.bw.dcn.clk.dramclk_khz > 
dc->clk_mgr->bw_params->dc_mode_softmax_memclk * 1000)
dc->clk_mgr->funcs->set_max_memclk(dc->clk_mgr, 
dc->clk_mgr->bw_params->clk_table.entries[dc->clk_mgr->bw_params->clk_table.num_entries
 - 1].memclk_mhz);
 
dcn20_prepare_bandwidth(dc, context);
+
+   dc_dmub_srv_p_state_delegate(dc, false, context);
 }
 
-- 
2.34.1