Bug 96916

Thanks for a good bug report. I know it's a lot to ask, but could you test whether connecting the display directly to the laptop (rather than through a docking station) makes a difference?

Also, could you try drm-intel-nightly? I realise it's a bit of a hassle, but there have been quite a lot of patches related to PSR (and to MST, which might be how your display is connected via the docking station) merged since the 4.6 kernel.

Sorry, forgot to mention that I did in fact test with yesterday's drm-intel-nightly before posting the bug report. Commit 9561f5c5e1918cfaeb2a39f90eed046730ae7399 to be precise.

Trying with the display directly connected to the laptop using a DP cable I get more or less the same results. Instead of screen flashes the screen goes completely blank though. It does come back when I move the mouse or run some compilation.

I'm also going to attach the results of the kms_psr_sink_crc kms_frontbuffer_tracking tests as was indicated by the Enable PSR commit. Took a while to find that "kms_psr_frontbuffer_tracking" as written in the commit message is not the correct name ;)

Please tell me where else I can dig to get you needed information.

Btw. the external display is a HP ZR24w

Created attachment 125073 [details]
Results of kms_psr_sink_crc tests

Created attachment 125074 [details]
Results of kms_frontbuffer_tracking tests

I've now tested this on a ThinkPad Yoga (I don't have access to any ThinkPad T440p) with a Core i5-4200U (HD Graphics 4400), and a HP ZR24w display connected via the mini-HDMI connector on that laptop.

With PSR enabled (/sys/module/i915/parameters/enable_psr == 1) and drm-intel-nightly from 28th of September I cannot reproduce this. I am *not* using the xserver-xorg-video-intel driver, my setup is using the xorg modesetting driver.

That's the only difference I can think of (except that I'm not using the except same laptop model, obviously).

I've tested setting the external display as a secondary display, and as a mirror, both worked as they should.

Before testing I ran powertop --auto-tune (to ensure that nothing blocks power management).

removing regression-keyword due to failure to be visible with parameter change on kernel. PSR is disabled on HSW by default at this point.

*** Bug 98583 has been marked as a duplicate of this bug. ***

Hello Nine,
Is this still reproducible on latest kernels? 
A lot of changes have been made since 4.7, could you try last drm-tip and check if the problem persist?
Thanks.

Sorry for the late reply.
On Saturday's drm-tip (4.13.0-rc3-6.g3a35823-default+) the issue is gone. Of course that's to be expected as PSR seems to be disabled by default:

> cat /sys/kernel/debug/dri/0/i915_edp_psr_status
Sink_Support: yes
Source_OK: no
Enabled: no
Active: no
Busy frontbuffer bits: 0x000
Re-enable work scheduled: no
Main link in standby mode: no
HW Enabled & Active bit: no
Performance_Counter: 0

(In reply to nine from comment #9)
> Sorry for the late reply.
> On Saturday's drm-tip (4.13.0-rc3-6.g3a35823-default+) the issue is gone. Of
> course that's to be expected as PSR seems to be disabled by default:
> 
> > cat /sys/kernel/debug/dri/0/i915_edp_psr_status
> Sink_Support: yes
> Source_OK: no
> Enabled: no
> Active: no
> Busy frontbuffer bits: 0x000
> Re-enable work scheduled: no
> Main link in standby mode: no
> HW Enabled & Active bit: no
> Performance_Counter: 0
Thanks for the updated. The bet is that now is detecting correctly that is a HSW. Then I'm proceeding to close this bug. If problem arise again please file a new bug with HW /SW information and logs. Thanks again.