Higher refresh rates not working on kernels >5.9

changed the description

added DC label

mentioned in issue #1442

mentioned in issue #1466 (closed)

changed the description

Added update to post

mentioned in issue #1482 (closed)

Can you bisect?

Hi Alex, how would i bisect?

https://www.kernel.org/doc/html/latest/admin-guide/bug-bisect.html

Took me some tinkering (15 kernel builds), but i'm here now:

098214999c8f8eea8dffddb61be5742fac2c829e is the first bad commit
commit 098214999c8f8eea8dffddb61be5742fac2c829e
Author: Igor Kravchenko <Igor.Kravchenko@amd.com>
Date:   Sun Jul 19 20:45:28 2020 -0400

    drm/amd/display: Read VBIOS Golden Settings Tbl
    
    [Why]
    For ver.4.4 and higher VBIOS contains default setting table.
    
    {How]
    Read Golden Settings Table from VBIOS, apply Aux tuning parameters.
    
    Signed-off-by: Igor Kravchenko <Igor.Kravchenko@amd.com>
    Reviewed-by: Aric Cyr <Aric.Cyr@amd.com>
    Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

 drivers/gpu/drm/amd/display/dc/bios/bios_parser.c  |  2 +
 drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c | 81 ++++++++++++++++++++++
 drivers/gpu/drm/amd/display/dc/core/dc_link.c      |  3 +
 drivers/gpu/drm/amd/display/dc/dc_bios_types.h     |  4 ++
 drivers/gpu/drm/amd/display/dc/dc_types.h          | 14 ++++
 .../gpu/drm/amd/display/dc/dce/dce_link_encoder.h  |  4 +-
 .../drm/amd/display/dc/dcn10/dcn10_link_encoder.h  | 10 ++-
 .../drm/amd/display/dc/dcn20/dcn20_link_encoder.c  | 14 +++-
 .../drm/amd/display/dc/dcn20/dcn20_link_encoder.h  |  5 +-
 drivers/gpu/drm/amd/include/atomfirmware.h         | 54 ++++++++++++++-
 10 files changed, 182 insertions(+), 9 deletions(-)

This patch should fix it.

0001-drm-amdgpu-display-restore-AUX_DPHY_TX_CONTROL-for-D.patch

Hi Alex. Thank you for the prompt response. I think i have to rectify some things here.

So the commit i shared after the bisection, does break the whole display. Your patch probably also fixes that (i have to read up on to applying patches etc to test it). Monitor was set at 240Hz in OSD at all times while bisecting.

However, i have not set the display itself to 240Hz in GDM. Once i do that, i'm seeing a ribbon on the bottom om my screen (artifacts). AND the display seems to randomly disconnect and reconnect. It is not there when on 120Hz. It is also not there when i turn down a notch to 2560x1440@240. However. it IS when woken from sleep (its even worse, get you a video shortly)

IMG_1367

Mind you, this display is just a few months old now, using the provided cabling. I've tried other display ports etc.

You can apply the patch to your git tree by something like: git am 0001-drm-amdgpu-display-restore-AUX_DPHY_TX_CONTROL-for-D.patch then rebuild and test.

If the flickering is also a regression you can try bisecting, but apply my patch on top of the commits which contain the original problematic patch (drm/amd/display: Read VBIOS Golden Settings Tbl). That will fix the display not working and you can bisect to the other commit that caused the flickering. It's a bit more work because you'll have to apply and remove the additional patch for each test.

So the commit i shared after the bisection, does break the whole display.

Can you be more specific? Does the display stop lighting up at all? Are only 240Hz modes broken?

Are you sure this commit is the one that breaks the display, i.e. does 240Hz work fine before this commit?

Can you confirm "https://pastebin.com/EA8kER7d" is for the good case, not the bad case? I'm asking since I see a failure with the EDID read and only 640x480 in the xrandr print.

This particular monitor is also problematic on our Windows driver and requires us to patch the timing definitions for the 240Hz timings. We currently don't have that timing override on Linux.

Hi Harry,

Can you be more specific? Does the display stop lighting up at all? Are only 240Hz modes broken? When the display is set at 240Hz in OSD (no adaptive-sync), the screen goes in standby (as if there is no input), after grub/systemd-boot.

I've tested archiso, which was at 5.10 if i recall. It only works when i force the monitor in 60Hz in OSD. As for the 5.4 logs, this is my fault. I'm unsure how i managed to get this EDID error. Frankly, when i got the monitor, i was running 5.8.

I'm using wayland, this paste was from when (i think), GDM failed to load wayland, and fell back to X. If you really want, can try to replicate this specific error.

As for the timings. nice to hear(?) there is some recognition. Sound like this is a fault at Samsung? Could it be related to firmware? (i'm running latest firmware on the monitor).

@agd5f 's patch, applied against 5.10.15, fixes my Odyssey G9 via DP with amdgpu on 5700 XT.

I was a little hesitant to jump on this issue because my symptoms were subtly different, but through barrages of restarts I've noticed that I very rarely get slightly different results, and given that the patch appears to have instantly fixed things for me, I expect it is the same thing.

My symptoms before the patch were:

120Hz -- No picture in X, monitor eventually enters standby. Switching to TTY is very rarely, but sometimes, possible, and monitor comes online again.
240Hz -- screenshot monstrosity included: IMG_20210217_182648__01
60Hz -- works!

I'm on 2/2 reboots with both 120Hz and 240Hz plus Freesync working 100% of the time, and before this patch I could never get 240Hz. Thank you!

Thanks for the clarification, @D0peX , and @srhb , for your confirmation that Alex's patch fixes this.

I'm not a fan of simply reverting the AUX_DPHY_TX_CONTROL programming since it will increase each AUX transaction by 600us, which adds up over many AUX transactions, such as when we link train a monitor while setting the mode.

I have 2 patches, based on Alex's patch, that should avoid that. I would be very grateful if one of you could give the patches a spin, especially Patch 1, the preferred solution.

The patches are mutually exclusive. They're merely 2 different ways to solve the problem.

Patch 1: force AUX_CTRL_4 programming

~~0001-drm-amdgpu-display-force-AUX_CTRL_4-programming-on-D.patch~~

edit, new patch: 0001-drm-amdgpu-display-force-AUX_CTRL_4-programming-on-D.patch

This patch sets up our AUX HW for the DPHY_TX_CONTROL programming. This was intended to be done in the VBIOS but apparently there are some boards out there (I have one myself) that don't do that. With this patch every board will be able to benefit from fast AUX transactions.

Patch 2: only use new DPHY_TX_CONTROL value for applicable VBIOS

~~0001-drm-amdgpu-display-only-use-new-DPHY_TX_CONTROL-valu.patch~~

edit, new patch: 0001-drm-amdgpu-display-only-use-new-DPHY_TX_CONTROL-valu.patch

This patch only uses the new DPHY_TX_CONTROL value on boards where VBIOS set up AUX_CTRL_4 correctly. This means that boards with older VBIOS get the old programming, and boards with newer VBIOS get the new programming.

edit: updated the patches. first version was reading/writing a bad register.

@hwentland I'm happy to try both, but I probably won't be able to report back until tomorrow or the day after.

Thanks, @srhb . Looking forward to hear about your results.

Please make sure to grab the new version of the patches in my edited comment. The first version was wrong.

Here are my results. Everything is applied against 5.11.0 -- if that's a problem, let me know and I'll redo. :)

0001-drm-amdgpu-display-force-AUX_CTRL_4-programming-on-D.patch: No dice, same problem as before. 120Hz does not get me a display while 240Hz is completely garbled.

0001-drm-amdgpu-display-only-use-new-DPHY_TX_CONTROL-valu.patch: Appears to initially boot up with either 120Hz or 240Hz, but switching from one to the other apparently hangs the systems; display enters standby, soft poweroff doesn't react.

0001-drm-amdgpu-display-restore-AUX_DPHY_TX_CONTROL-for-D.patch still works for either 120Hz or 240Hz and switching does not crash the system.

I have zero expertise in this area, so I don't know what other information might be relevant to you. If you need something specific, I can easily boot into either of these configurations now, however, as long as I have instructions. :)

I also have an update regarding the patches.

Patch 1: (i have journals for each Hz, for each boot separate if need be)

240Hz - No signal. Goes in to sleep.

120Hz - does boot. Wayland/GDM loads in 1024x768@60Hz. Not many options either. There is some sort of 'grain' artifact (static, not flickering or anything).

60Hz - Booted. GDM loaded in at 3840x1080 (might be a safe GDM default?). However 5120x1440 was an option and it worked. This was the case before as well. 60Hz at full res was working al along.

Patch 2:

240Hz - GDM starts at native resolution, but at 60Hz. Setting display at 240Hz works. Again, this might be a safe default from GDM. Also; NO artifacting like i've mentioned 3 days ago (as seen in IMG_1367). Before i had issues after waking from sleep as well. Heavy artifacting at 240Hz, not at 120. This is not the case now.

120Hz - Same thing. Works, had to set native res and 120Hz. No issues after that. Also not after sleep.

60HZ - I think we know how this works. Did not test.

Switchting 'live' in OSD from 120Hz to 240, also works without issues.

I seem tho have the same HW as Sarah. Might there be a difference in VBIOS version? I've been trying to find it, but cant. I am using Wayland though, Sarah is using X if i remember correctly. Since Sarah and I both had in patch1 somewhat similar results, however i did not get the heavy artifacts. Might X11 force the full res on 120Hz, while Wayland dials down to lower res? I don't know...

Edit: I'd have to rectify and possibly test some more. But my pc went to 'powersave' mode (only turns display off) whilst i was afk (240Hz). Once i got back i mashed my keyboard to get signal back, but that did not happen. This was on Patch2. Also forcing the displag back on, switching input, and hitting powerbtn on my pc did nothing.

Paste with logs from when the 'powersave' started: https://pastebin.com/rXr7mz7g

mentioned in commit agd5f/linux@801ae7a0

mentioned in commit agd5f/linux@30a3e830

mentioned in commit agd5f/linux@e8af38ec

mentioned in commit agd5f/linux@5c458585

mentioned in commit agd5f/linux@f9cd790d

This issue hasn't had any activity since 2021-03-26. The AMD driver stack changes rapidly and contains lots of shared code across products so it's possible that it has already been fixed. Please upgrade to a current stable kernel and userspace stack and try again. If you still experience this issue with the latest driver stack, please capture relevant logging and open a new issue referring back to this one.

closed

Higher refresh rates not working on kernels >5.9

Brief summary of the problem:

Hardware description:

System infomration:

How to reproduce the issue:

Attached files:

Designs

Child items 0

Activity

Admin message

Admin message

Higher refresh rates not working on kernels >5.9

Brief summary of the problem:

Hardware description:

System infomration:

How to reproduce the issue:

Attached files:

Activity