Created attachment 142108 [details] dmesg output from booting drm-tip with drm.debug=0x1e and psr enabled Current drm-tip contains commit 598c6cfe06900505ae16a355599e9f08432f4d7a (drm/i915/psr: Enable PSR1 on gen-9+ HW). On a MacBookPro13,3 (Skylake, gen9 gpu) this results in the screen flashing at about 3Hz when the display has no changes. Removing that commit or booting with i915.enable_psr=0 fixes this again.
Created attachment 142109 [details] contents of /sys/kernel/debug/dri/0/i915_edp_psr_status
Created attachment 142110 [details] output from 'edid-decode /sys/class/drm/card0-eDP-1/edid'
Created attachment 142111 [details] contents of /sys/kernel/debug/dri/0/i915_capabilities
Hi Could you give a try with this patches? https://patchwork.freedesktop.org/series/50843/ There is a lot of short pulses from you panel that are probably PSR errors that need to handled instead of train the link.
> Could you give a try with this patches? https://patchwork.freedesktop.org/series/50843/ Applied that on on top of today's drm-tip: it changes the behaviour somewhat, but doesn't fix it. Now the display goes and stays blank when there are no updates (instead of flashing continuously at 3Hz) - whenever there is an update (e.g. moving the mouse) the display comes on again until the updates stop.
Created attachment 142146 [details] dmesg output from booting drm-tip with drm.debug=0x1e and psr enabled, with patch series applied
Okay no more retraining but DPCD are still failing =/ [ 13.694862] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on port A - short [ 13.695004] [drm:dc_link_handle_hpd_rx_irq [amdgpu]] dc_link_handle_hpd_rx_irq: Got short pulse HPD on link 0 [ 13.695586] [drm:intel_dp_read_dpcd [i915]] DPCD: 11 0a 84 41 00 00 01 80 02 00 00 00 0f 0b 00 [ 13.738161] [drm:drm_dp_dpcd_access [drm_kms_helper]] Too many retries, giving up. First error: -5 [ 13.738209] [drm:dc_link_handle_hpd_rx_irq [amdgpu]] dc_link_handle_hpd_rx_irq: DPCD read failed to obtain irq data [ 13.947377] [drm:dm_irq_work_func [amdgpu]] DM_IRQ: work_func: for dal_src=7 [ 13.947443] [drm:gen8_de_irq_handler [i915]] hotplug event received, stat 0x01000000, dig 0x11101010, pins 0x00000010, long 0x00000000 Also looks like panel is lines are muxed with the discrete GPU I will look at the implication of this.
(In reply to Jose Roberto de Souza from comment #7) > Also looks like panel is lines are muxed with the discrete GPU I will look > at the implication of this. Correct: MacBookPro's have a gmux - see also drivers/platform/x86/apple-gmux.c
Created attachment 142181 [details] [review] patch dropping psr exits from frontbuffer
Hi Ronald I have a few things for you to test to me: - can you check if your userspace is not trying to mirror or extend your desktop to 2 monitors? if so disable one. By the logs I can see that both GPUs have one CRTC and one plane enabled so maybe the mux is not working and both GPUs are driving/trying to drive the same panel - can you disable the AMD GPU in BIOS or blacklist the module and test it? - can you apply this patch https://bugs.freedesktop.org/attachment.cgi?id=142181 on top of drm-tip and test it?(with AMD GPU still disabled) - can you apply this patch https://bugs.freedesktop.org/attachment.cgi?id=142181 on top of drm-tip + https://patchwork.freedesktop.org/series/50843/ and test it?(with AMD GPU still disabled) Thanks
(In reply to Jose Roberto de Souza from comment #10) > Hi Ronald > > I have a few things for you to test to me: > > - can you check if your userspace is not trying to mirror or extend your > desktop to 2 monitors? if so disable one. By the logs I can see that both > GPUs have one CRTC and one plane enabled so maybe the mux is not working and > both GPUs are driving/trying to drive the same panel I'm quite sure the userspace is not mirroring/extending, and that the gmux is working correctly. However, I believe what you're seeing is probably due to the fact that the dGPU (AMD), and only the dGPU, is wired up to the external DP (in order to use an external monitor the dGPU has to be enabled - e.g. I usually power down the dGPU to save power (via vgaswitcheroo), but have to power it back up if I want to use an external monitor). > - can you disable the AMD GPU in BIOS or blacklist the module and test it? Done: no change. (blacklisted the module, verified it didn't show up in lsmod after boot and /sys/kernel/debug/vgaswitcheroo was not present anymore). > - can you apply this patch > https://bugs.freedesktop.org/attachment.cgi?id=142181 on top of drm-tip and > test it?(with AMD GPU still disabled) Done: slightly worse: seems to flicker a bit faster. > - can you apply this patch > https://bugs.freedesktop.org/attachment.cgi?id=142181 on top of drm-tip + > https://patchwork.freedesktop.org/series/50843/ and test it?(with AMD GPU > still disabled) Done: slightly worse than series-only, in that it appears to be harder to get the display to render (e.g. while typing in the encrypted-disk password early in boot the display stays blank, whereas with series-only it will flash on as I type).
Created attachment 142191 [details] dmesg output from booting drm-tip, no patches, admgpu disabled
Created attachment 142192 [details] dmesg output from booting drm-tip, no patches, admgpu disabled
Created attachment 142193 [details] dmesg output from booting drm-tip, drop-frontbuffer-exits patch, admgpu disabled
Created attachment 142194 [details] dmesg output from booting drm-tip, series 50843 + drop-frontbuffer-exits patch, admgpu disabled
Thanks for the tests. In this setup: > > - can you apply this patch > > https://bugs.freedesktop.org/attachment.cgi?id=142181 on top of drm-tip + > > https://patchwork.freedesktop.org/series/50843/ and test it?(with AMD GPU > > still disabled) >Done: slightly worse than series-only, in that it appears to be harder to get the display to render (e.g. while typing in the encrypted-disk password early in >boot the display stays blank, whereas with series-only it will flash on as I type) It fixed the blank screen when there is no updates in the screen?
(In reply to Jose Roberto de Souza from comment #16) > > > - can you apply this patch > > > https://bugs.freedesktop.org/attachment.cgi?id=142181 on top of drm-tip + > > > https://patchwork.freedesktop.org/series/50843/ and test it?(with AMD GPU > > > still disabled) > >Done: slightly worse than series-only, in that it appears to be harder to get the display to render (e.g. while typing in the encrypted-disk password early in >boot the display stays blank, whereas with series-only it will flash on as I type) > > It fixed the blank screen when there is no updates in the screen? No. Sorry if I wasn't clear - let me explain in more detail. First of all, just to be clear, when I say "blank" I mean a black screen, but backlight is still on. Now, with just the series 50843 applied, the behaviour is that on any screen update the display will briefly render and then go blank again shortly (on the order of 200ms - 300ms) after the updates cease. With the drop-frontbuffer-exits patch on top, this changes in that not all screen updates will cause the display to be rendered, i.e. in a number of cases the screen stays blank despite the screen having been updated. In particular this happens (or at least is most noticeable) when the disk-password prompt is displayed during boot: without this patch, every time a character is entered (and hence another * is displayed in the prompt) the screen briefly renders - with this patch the screen stays blank the whole time. Only when switching between graphical password prompt and console (the esc key) does the screen briefly render. This behaviour continues then through the boot animation (this is on Fedora, where it shows an empty Fedora icon/logo that is slowly being filled in), i.e. without the patch the logo appears (since the screen is being constantly updated), but with the patch the screen stays blank - it's not until we get to a late stage with the full logo present and then login manager where the behaviour appears to then be the same as without the patch, i.e. the is screen rendered on every update. Hope this is clearer.
Thanks for all the information so far Ronald. Could you try again with amdgpu disabled + this patches? https://github.com/zehortigoza/linux/commits/psr-debug-108503 It is rebased over drm-tip from today so you can just checkout this or cherry-pick the last 10 patches. Thanks for helping debug this, we are still trying to get a similar MacBook to try this by ourselves.
(In reply to Jose Roberto de Souza from comment #18) > Could you try again with amdgpu disabled + this patches? > https://github.com/zehortigoza/linux/commits/psr-debug-108503 Done: same behaviour as just series 50843 patches, i.e. display briefly renders while there are updates and goes blank shortly after they cease. > Thanks for helping debug this, we are still trying to get a similar MacBook > to try this by ourselves. I believe this behaviour should present on all MBP13,* and MBP14,* (i.e. late 2016 and mid 2017 models) - don't get a 2018 model, as those aren't really working yet at all. Thanks for keeping working on this - happy to run any tests/patches/etc you need.
Created attachment 142403 [details] dmesg output from booting psr-debug-108503, admgpu disabled
(In reply to Jose Roberto de Souza from comment #18) > Thanks for all the information so far Ronald. > > Could you try again with amdgpu disabled + this patches? > https://github.com/zehortigoza/linux/commits/psr-debug-108503 > > It is rebased over drm-tip from today so you can just checkout this or > cherry-pick the last 10 patches. > > Thanks for helping debug this, we are still trying to get a similar MacBook > to try this by ourselves. It seems like the panel doesn't recognize that the GPU is putting it in a self-refresh mode. We can read PSR sink status DPCD when the screen is idle through ssh and confirm if the sink has entered PSR. We could perhaps try disabling CRC too as a way to configure a safer setup. I'd also recommend not using the fastboot command line option for debug purpose. Ronald, Does the screen back up after it goes black (via a mouse or keyboard action)?
Created attachment 142415 [details] script to get some sink psr registers
Hi Ronald So I updated https://github.com/zehortigoza/linux/commits/psr-debug-108503 with a change to disable CRC check in sink as Dhinakaran suggested. Could you run it again with amdgpu disabled and also could you ssh into your machine and run this script(https://bugs.freedesktop.org/attachment.cgi?id=142415) while screen is blank? Just make sure your kernel config have CONFIG_DRM_DP_AUX_CHARDEV=y Thanks again
(In reply to Dhinakaran Pandiyan from comment #21) > I'd also recommend not using the fastboot command line option for debug > purpose. Will do. > Ronald, > Does the screen back up after it goes black (via a mouse or keyboard action)? Sorry, I'm not sure I correctly understand what you mean by "back up"? If you're asking whether the screen displays properly again when the mouse is moved or some keyboard action triggers a display update, then yes; and when the display updates cease for 200ms or 300ms it goes blank again.
Hi Jose, (In reply to Jose Roberto de Souza from comment #23) > So I updated https://github.com/zehortigoza/linux/commits/psr-debug-108503 > with a change to disable CRC check in sink as Dhinakaran suggested. > Could you run it again with amdgpu disabled and also could you ssh into your > machine and run this > script(https://bugs.freedesktop.org/attachment.cgi?id=142415) while screen > is blank? > Just make sure your kernel config have CONFIG_DRM_DP_AUX_CHARDEV=y Done. Here is the output from the script while the screen is visible: 0x170=01 0x2006=00 0x2007=00 0x2008=00 0x2009=08 0x200A=00 And this is the output when the screen is blank: 0x170=01 0x2006=00 0x2007=00 0x2008=00 0x2009=08 0x200A=01 Lastly, not sure if all this info is in the log (didn't see it, but could've missed it) or if it's useful to you, but there is the full output from /sys/kernel/debug/dri/0/eDP-1/i915_dpcd: 0000: 11 0a 84 41 00 00 01 80 02 00 00 00 0f 0b 00 0070: 01 01 0080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0100: 0a 84 00 00 00 00 00 00 01 08 00 0200: 01 00 77 77 01 01 00 00 0600: 01 0700: 02 0701: 83 97 00 00 0720: 81 04 00 00 10 0f 0f 00 00 00 00 00 00 00 00 00 0732: 00 00
Created attachment 142417 [details] dmesg output from booting psr-debug-108503 rev 2, admgpu disabled
(In reply to Ronald from comment #25) > Lastly, not sure if all this info is in the log (didn't see it, but could've > missed it) or if it's useful to you, but there is the full output from > /sys/kernel/debug/dri/0/eDP-1/i915_dpcd: > > 0000: 11 0a 84 41 00 00 01 80 02 00 00 00 0f 0b 00 > 0070: 01 01 > 0080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0100: 0a 84 00 00 00 00 00 00 01 08 00 > 0200: 01 00 77 77 01 01 00 00 > 0600: 01 > 0700: 02 > 0701: 83 97 00 00 > 0720: 81 04 00 00 10 0f 0f 00 00 00 00 00 00 00 00 00 > 0732: 00 00 Sorry, the above was actually from a different kernel. For psr-debug-108503 rev 2 the 0200 line reads as follows (the rest is identical): display blank: 0200: 01 00 33 33 80 00 00 00 display visible: 0200: 01 00 77 77 81 01 00 00
Thanks Ronald. Huum so register 0x200A(LAST RECEIVED PSR SDP) have PSR state bit set but register 0x2008(SINK DEVICE SELF REFRESH STATUS) is in PSR inactive state. Maybe this panel have a different PSR entry sequence. Thoughts DK?
Hi Ronald Talking with the MacOS team, they told us that Apple has a proprietary implementation of PSR, so we will have to disable it for every Apple panel =/ Anyway thanks for helping us out.
The first patch of this series: https://patchwork.freedesktop.org/series/53043/ Should take care of this
(In reply to Jose Roberto de Souza from comment #29) > Talking with the MacOS team, they told us that Apple has a proprietary > implementation of PSR, so we will have to disable it for every Apple panel =/ > > Anyway thanks for helping us out. Bummer, though unfortunately not too surprising. Thanks for looking into this. (In reply to Jose Roberto de Souza from comment #30) > The first patch of this series: > https://patchwork.freedesktop.org/series/53043/ > Should take care of this I can confirm this works as advertised - I verified the flashing was still there with current drm-tip and that it was gone with the first patch from the series applied on top of drm-tip.
Patch merged
Fix confirmed by reporter, closing.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.