You are not logged in.
Pages: 1
Trying to work out how to turn on Panel Self Refresh with AMDGPU. I seem to have successfully enabled the driver, but I that has not actually "turned it on".
There doesn't seem to be much public info about PSR in relation to AMD, and most of what I see about Intel seems to indicate that the 1 kernel param enables/disables both the driver and the feature at the same time. Not sure how to proceed from here. Also not sure how to verify the feature is actually working beyond hopefully a nice drop in power usage showing in PowerTOP.
---
Apply feature mask that includes PSR.
0x1 -> DC_FBC_MASK
0x2 -> DC_MULTI_MON_PP_MCLK_SWITCH_MASK
0x8 -> DC_PSR_MASK
and 0x1 + 0x2 + 0x8 = 0xB
# systemd-boot conf file
...
initrd /initramfs-linux-zen.img
options root=UUID= ... amdgpu.dcfeaturemask=0xB ...
Driver enabled? Looking good.
$ sudo cat /sys/kernel/debug/dri/0/eDP-1/psr_capability
Sink support: yes [0x03]
Driver support: yes
Feature enabled? Not so much.
$ sudo cat /sys/kernel/debug/dri/0/eDP-1/psr_state
0
---
GPU info.
sudo lspci -v -s 04:00.0
04:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Renoir (rev c3) (prog-if 00 [VGA controller])
DeviceName: AMD Radeon(TM) Graphics
Subsystem: Hewlett-Packard Company Device 876e
Flags: bus master, fast devsel, latency 0, IRQ 40, IOMMU group 5
Memory at fce0000000 (64-bit, prefetchable) [size=256M]
Memory at fcf0000000 (64-bit, prefetchable) [size=2M]
I/O ports at 1000 [size=256]
Memory at d0400000 (32-bit, non-prefetchable) [size=512K]
Capabilities: [48] Vendor Specific Information: Len=08 <?>
Capabilities: [50] Power Management version 3
Capabilities: [64] Express Legacy Endpoint, MSI 00
Capabilities: [a0] MSI: Enable- Count=1/4 Maskable- 64bit+
Capabilities: [c0] MSI-X: Enable+ Count=4 Masked-
Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
Capabilities: [270] Secondary PCI Express
Capabilities: [2b0] Address Translation Service (ATS)
Capabilities: [2c0] Page Request Interface (PRI)
Capabilities: [2d0] Process Address Space ID (PASID)
Capabilities: [400] Data Link Feature <?>
Capabilities: [410] Physical Layer 16.0 GT/s <?>
Capabilities: [440] Lane Margining at the Receiver <?>
Kernel driver in use: amdgpu
Kernel modules: amdgpu
Offline
options root=UUID= ... amdgpu.dcfeaturemask=0xB ...
This way.
Are you positive that the panel actually supports PSR?
Also check https://gitlab.freedesktop.org/drm/amd/-/issues/1474 your system journal and "cat /proc/cmdline"
PSR is supposed to be enabled by default anyway, https://www.phoronix.com/scan.php?page= … x-5.16-PSR
Offline
Are you positive that the panel actually supports PSR?
Honestly, no. I am not sure. However:
A linux-hardware.org probe reports my display as (Chimei Innolux) model CMN139D, which seems to be an alias for N133HCG-GF3. And PaneLook.com claims said model supports PSR2
I'm not seeing anything at this link that adds additional info. Do you see something specific there that looks potentially useful?
Also check ... your system journal and "cat /proc/cmdline"
$ sudo cat /proc/cmdline
initrd=\amd-ucode.img initrd=\initramfs-linux-zen.img root=UUID={my-root-drive-uuid} rw resume=UUID={my-root-drive-uuid} resume_offset=2064384 tsc=directsync amdgpu.dcfeaturemask=0xB
$ journalctl -p 3 -xb
May 13 12:22:57 envy login[317]: gkr-pam: unable to locate daemon control file
$ journalctl -b | grep 'psr\|PSR'
May 13 12:22:50 envy kernel: [drm] PSR support:1
May 13 12:26:04 envy sudo[11722]: {my-username} : TTY=pts/1 ; PWD=/home/{my-username} ; USER=root ; COMMAND=/usr/bin/cat /sys/kernel/debug/dri/0/eDP-1/psr_capability
May 13 12:28:42 envy sudo[17334]: {my-username} : TTY=pts/1 ; PWD=/home/{my-username} ; USER=root ; COMMAND=/usr/bin/cat /sys/kernel/debug/dri/0/eDP-1/psr_state
So we see the expected boot command with the PSR-enabling mask; that the kernel recognized the param and matched it to PSR support; no relevant error-level logs; and that I used `sudo` to check the status of the capability and the state. Trying to scroll through the entire log, nothing jumps out at me, but perhaps there is something else specific I should look for?
PSR is supposed to be enabled by default anyway, https://www.phoronix.com/scan.php?page= … x-5.16-PSR
enabling PSR by default on newer DCN hardware ... with DCN 3.1. PUs with pre-DCN-3.1 hardware are keeping PSR off for now.
I bought this computer (with it's Ryzen 5 4500U) in May 2020, and this article was published in Oct 2021. I don't know where to look up my version of DCN, but I strongly suspect I fall under "pre-DCN-3.1".
I can say for sure that, in my case, the driver was not enabled until asking for it with the `dcfeaturemask`.
# Before adding PSR to dcfeaturemask
$ sudo cat /sys/kernel/debug/dri/0/eDP-1/psr_capability
Sink support: no
Driver support: no [0xffffffff]
# After adding PSR to dcfeaturemask
$ sudo cat /sys/kernel/debug/dri/0/eDP-1/psr_capability
Sink support: yes [0x03]
Driver support: yes
Last edited by skylize (2022-05-13 17:42:18)
Offline
https://gitlab.freedesktop.org/drm/amd/-/issues/1474 was to point out that this happens when resuming and to ensure that you don't meet this condition (somehow) when checking for the status and also to illustrate that there pending issues w/ PSR
There's also a more recent reddit thread, https://www.reddit.com/r/linuxhardware/ … md_renoir/ - also a CMN panel…
A linux-hardware.org
better check the EDID.
DCN-3.1 is actually *just* YELLOW CARP, https://www.x.org/wiki/RadeonFeature/
Renoir is only 2.1
no relevant error-level logs
I'd rather grep for amdgpu (if the panel isn't considered to support PSR, that's not exactly an "error")
There's also a massive patch for PSR2/-SU in the pipeline, https://lore.kernel.org/all/20220510204 … amd.com/T/ but idk whether that's relevant in your case (ie. whether the panel is disregarded *because* it does PSR2)
Finally: since userspace/compositor issues are mentioned - did you check the state w/o any display server (from the multi-user.target) to avoid a situation where the driver maybe responds to certain access patterns by disabling PSR to avoid artifacts?
Offline
to point out that this happens when resuming
Happens on fresh boot.
There's also a more recent reddit thread
Yeah, he seems to be in the same boat. Though I'm one step closer in having found a proper model number for the display, and verified it ''should'' support PSR (...in some form or another... in theory. ).
DCN-3.1 is actually *just* YELLOW CARP ... Renoir is only 2.1
So yeah. Doesn't apply.
better check the EDID
Block 0, Base EDID:
EDID Structure Version & Revision: 1.4
Vendor & Product Identification:
Manufacturer: CMN
Model: 5021
Made in: week 50 of 2018
Basic Display Parameters & Features:
Digital display
Bits per primary color channel: 8
DisplayPort interface
Maximum image size: 29 cm x 17 cm
Gamma: 2.20
Supported color formats: RGB 4:4:4
First detailed timing includes the native pixel format and preferred refresh rate
Display is continuous frequency
Color Characteristics:
Red : 0.6396, 0.3300
Green: 0.2998, 0.5996
Blue : 0.1503, 0.0595
White: 0.3134, 0.3291
Established Timings I & II: none
Standard Timings: none
Detailed Timing Descriptors:
DTD 1: 1920x1080 60.001038 Hz 16:9 66.721 kHz 138.780000 MHz (293 mm x 165 mm)
Hfront 48 Hsync 32 Hback 80 Hpol P
Vfront 3 Vsync 5 Vback 24 Vpol N
DTD 2: 1920x1080 40.000692 Hz 16:9 44.481 kHz 92.520000 MHz (293 mm x 165 mm)
Hfront 48 Hsync 32 Hback 80 Hpol P
Vfront 3 Vsync 5 Vback 24 Vpol N
Empty Descriptor
Manufacturer-Specified Display Descriptor (0x02): 00 02 00 0c 26 ff 14 3c c8 0a 05 11 c8 00 00 00 '....&..<........'
Checksum: 0x89
Nothing informative there. According to big_belarusian on Reddit, this would not be be expected to show in EDID, instead being read from 0x070 of the panel's DPCD register. He suggests reading it from debugfs, but on my system the file he points to is empty.
$ sudo cat /sys/kernel/debug/dri/0/eDP-1/aux_dpcd_data
# <nothing>
whether the panel is disregarded *because* it does PSR2
<yikes> I hope not. How would I know?
did you check the state w/o any display server
Fresh boot, before starting Sway. Same result.
I'd rather grep for amdgpu
May 14 19:02:16 archlinux kernel: Command line: initrd=\amd-ucode.img initrd=\initramfs-linux-zen.img root=UUID=bd54aa83-86ff-461a-ac6e-b563f86c9d6a rw resume=UUID=bd54aa83-86ff-461a-ac6e-b563f86c9d6a resume_offset=2064384 tsc=directsync amdgpu.dcfeaturemask=0xB
May 14 19:02:16 archlinux kernel: Kernel command line: initrd=\amd-ucode.img initrd=\initramfs-linux-zen.img root=UUID=bd54aa83-86ff-461a-ac6e-b563f86c9d6a rw resume=UUID=bd54aa83-86ff-461a-ac6e-b563f86c9d6a resume_offset=2064384 tsc=directsync amdgpu.dcfeaturemask=0xB
May 14 19:02:18 envy kernel: [drm] amdgpu kernel modesetting enabled.
May 14 19:02:18 envy kernel: amdgpu: Virtual CRAT table created for CPU
May 14 19:02:18 envy kernel: amdgpu: Topology: Add CPU node
May 14 19:02:18 envy kernel: fb0: switching to amdgpu from EFI VGA
May 14 19:02:18 envy kernel: amdgpu 0000:04:00.0: vgaarb: deactivate vga console
May 14 19:02:18 envy kernel: amdgpu 0000:04:00.0: enabling device (0006 -> 0007)
May 14 19:02:18 envy kernel: amdgpu 0000:04:00.0: amdgpu: Trusted Memory Zone (TMZ) feature enabled
May 14 19:02:18 envy kernel: amdgpu 0000:04:00.0: amdgpu: Fetched VBIOS from VFCT
May 14 19:02:18 envy kernel: amdgpu: ATOM BIOS: 113-RENOIR-031
May 14 19:02:18 envy kernel: amdgpu 0000:04:00.0: amdgpu: PCIE atomic ops is not supported
May 14 19:02:18 envy kernel: amdgpu 0000:04:00.0: amdgpu: VRAM: 512M 0x000000F400000000 - 0x000000F41FFFFFFF (512M used)
May 14 19:02:18 envy kernel: amdgpu 0000:04:00.0: amdgpu: GART: 1024M 0x0000000000000000 - 0x000000003FFFFFFF
May 14 19:02:18 envy kernel: amdgpu 0000:04:00.0: amdgpu: AGP: 267419648M 0x000000F800000000 - 0x0000FFFFFFFFFFFF
May 14 19:02:18 envy kernel: [drm] amdgpu: 512M of VRAM memory ready
May 14 19:02:18 envy kernel: [drm] amdgpu: 3072M of GTT memory ready.
May 14 19:02:18 envy kernel: amdgpu 0000:04:00.0: amdgpu: PSP runtime database doesn't exist
May 14 19:02:18 envy kernel: amdgpu 0000:04:00.0: amdgpu: Will use PSP to load VCN firmware
May 14 19:02:19 envy kernel: amdgpu 0000:04:00.0: amdgpu: RAS: optional ras ta ucode is not available
May 14 19:02:19 envy kernel: amdgpu 0000:04:00.0: amdgpu: RAP: optional rap ta ucode is not available
May 14 19:02:19 envy kernel: amdgpu 0000:04:00.0: amdgpu: SECUREDISPLAY: securedisplay ta ucode is not available
May 14 19:02:19 envy kernel: amdgpu 0000:04:00.0: amdgpu: SMU is initialized successfully!
May 14 19:02:19 envy kernel: snd_hda_intel 0000:04:00.1: bound 0000:04:00.0 (ops amdgpu_dm_audio_component_bind_ops [amdgpu])
May 14 19:02:19 envy kernel: kfd kfd: amdgpu: Allocated 3969056 bytes on gart
May 14 19:02:19 envy kernel: amdgpu: HMM registered 512MB device memory
May 14 19:02:19 envy kernel: amdgpu: SRAT table not found
May 14 19:02:19 envy kernel: amdgpu: Virtual CRAT table created for GPU
May 14 19:02:19 envy kernel: amdgpu: Topology: Add dGPU node [0x1636:0x1002]
May 14 19:02:19 envy kernel: kfd kfd: amdgpu: added device 1002:1636
May 14 19:02:19 envy kernel: amdgpu 0000:04:00.0: amdgpu: SE 1, SH per SE 1, CU per SH 8, active_cu_number 6
May 14 19:02:19 envy kernel: amdgpu 0000:04:00.0: amdgpu: ring gfx uses VM inv eng 0 on hub 0
May 14 19:02:19 envy kernel: amdgpu 0000:04:00.0: amdgpu: ring comp_1.0.0 uses VM inv eng 1 on hub 0
May 14 19:02:19 envy kernel: amdgpu 0000:04:00.0: amdgpu: ring comp_1.1.0 uses VM inv eng 4 on hub 0
May 14 19:02:19 envy kernel: amdgpu 0000:04:00.0: amdgpu: ring comp_1.2.0 uses VM inv eng 5 on hub 0
May 14 19:02:19 envy kernel: amdgpu 0000:04:00.0: amdgpu: ring comp_1.3.0 uses VM inv eng 6 on hub 0
May 14 19:02:19 envy kernel: amdgpu 0000:04:00.0: amdgpu: ring comp_1.0.1 uses VM inv eng 7 on hub 0
May 14 19:02:19 envy kernel: amdgpu 0000:04:00.0: amdgpu: ring comp_1.1.1 uses VM inv eng 8 on hub 0
May 14 19:02:19 envy kernel: amdgpu 0000:04:00.0: amdgpu: ring comp_1.2.1 uses VM inv eng 9 on hub 0
May 14 19:02:19 envy kernel: amdgpu 0000:04:00.0: amdgpu: ring comp_1.3.1 uses VM inv eng 10 on hub 0
May 14 19:02:19 envy kernel: amdgpu 0000:04:00.0: amdgpu: ring kiq_2.1.0 uses VM inv eng 11 on hub 0
May 14 19:02:19 envy kernel: amdgpu 0000:04:00.0: amdgpu: ring sdma0 uses VM inv eng 0 on hub 1
May 14 19:02:19 envy kernel: amdgpu 0000:04:00.0: amdgpu: ring vcn_dec uses VM inv eng 1 on hub 1
May 14 19:02:19 envy kernel: amdgpu 0000:04:00.0: amdgpu: ring vcn_enc0 uses VM inv eng 4 on hub 1
May 14 19:02:19 envy kernel: amdgpu 0000:04:00.0: amdgpu: ring vcn_enc1 uses VM inv eng 5 on hub 1
May 14 19:02:19 envy kernel: amdgpu 0000:04:00.0: amdgpu: ring jpeg_dec uses VM inv eng 6 on hub 1
May 14 19:02:19 envy kernel: [drm] Initialized amdgpu 3.44.0 20150101 for 0000:04:00.0 on minor 0
May 14 19:02:19 envy kernel: fbcon: amdgpudrmfb (fb0) is primary device
May 14 19:02:19 envy kernel: amdgpu 0000:04:00.0: [drm] fb0: amdgpudrmfb frame buffer device
May 14 19:02:19 envy systemd[1]: Starting Load/Save Screen Backlight Brightness of backlight:amdgpu_bl0...
May 14 19:02:19 envy systemd[1]: Finished Load/Save Screen Backlight Brightness of backlight:amdgpu_bl0.
May 14 19:02:19 envy audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-backlight@backlight:amdgpu_bl0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Last edited by skylize (2022-05-15 00:00:11)
Offline
How would I know?
Proof-read the amdgpu kernel code… or hope for the pending patch.
but on my system the file he points to is empty
There's at least no "[drm:retrieve_link_cap [amdgpu]] *ERROR* retrieve_link_cap: Read dpcd data failed." or the likes.
You could try passing "drm.debug=0xff" to the kernel.
"should™"
Offline
You could try passing "drm.debug=0xff" to the kernel.
8000+ lines of debug after initial login in the getty, from`journalctl -b | grep -i drm`.
Mostly meaninless to me, but PSR shows up a few times:
452 May 15 18:26:27 envy kernel: [drm] PSR support:1
...
717 May 15 18:26:28 envy kernel: [drm:amdgpu_dm_psr_disable_all [amdgpu]] Disabling psr if psr is enabled on any stream
...
783 May 15 18:26:28 envy kernel: [drm:amdgpu_dm_link_setup_psr [amdgpu]] PSR link: 1
If I'm reading this patch correctly, `amdgpu_dm_psr_disable_all` should lead only to temporary disablement, for safety during connection/disconnection.
The problem seems to show in lines 784 - 785, while trying to commit the changes from 783. I would guess `-1` indicates failure here. But that doesn't offer much in the way of "why".
783 May 15 18:26:28 envy kernel: [drm:amdgpu_dm_link_setup_psr [amdgpu]] PSR link: 1
784 May 15 18:26:28 envy kernel: [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] Notify ELD: -1
785 May 15 18:26:28 envy kernel: [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] Notify ELD: -1
"Notify ELD" comes from code dealing with audio components. Unrelated.
Last edited by skylize (2022-05-15 23:50:40)
Offline
Hmm. Slightly more descriptive "why" is that it's a "hardware failure". Not looking good for me, is it? ....
from drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
/**
* amdgpu_dm_atomic_commit_tail() - AMDgpu DM's commit tail implementation.
* @state: The atomic state to commit
*
* This will tell DC to commit the constructed DC state from atomic_check,
* programming the hardware. Any failures here implies a hardware failure, since
* atomic check should have filtered anything non-kosher.
*/
static void amdgpu_dm_atomic_commit_tail(struct drm_atomic_state *state)
{
`amdgpu_dm_atomic_commit_tail` is not failing on display-related code, so is not an indicator of problems with PSR.
Last edited by skylize (2022-05-15 23:55:42)
Offline
Pages: 1