diff options
author | Jouni Högander <jouni.hogander@intel.com> | 2024-10-29 15:24:15 +0300 |
---|---|---|
committer | Jouni Högander <jouni.hogander@intel.com> | 2024-11-04 11:37:22 +0300 |
commit | facde55b6fca80fc6c8d051e932085bd3e7c6d04 (patch) | |
tree | a53476a724fb13aa5fec6ee32ebd0492e5faab83 /tools/perf/scripts/python/gecko.py | |
parent | ea9f962b1ff6eeeca15415cee1a4f1dbb2ce8e41 (diff) | |
download | linux-facde55b6fca80fc6c8d051e932085bd3e7c6d04.tar.xz |
drm/i915/psr: WA for panels stating bad link status after PSR is enabled
We are currently seeing unexpected link trainings with several different
eDP panels. These are caused by these panels stating bad link status in
their dpcd registers. This can be observed by doing following test:
1. Boot up without Xe module loaded
2. Load Xe module with PSR disabled:
$ modprobe xe enable_psr=0
3. Read panel link status register
$ dpcd_reg read --offset 0x200e --count=1
0x200e: 00
4. Enable PSR, sleep for 2 seconds and disable PSR again:
$ echo 0x1 > /sys/kernel/debug/dri/0/i915_edp_psr_debug
$ echo "-1" > /sys/kernel/debug/dri/0000:00:02.0/xe_params/enable_psr
$ echo 0x0 > /sys/kernel/debug/dri/0/i915_edp_psr_debug
$ sleep 2
$ cat /sys/kernel/debug/dri/0/i915_edp_psr_status | grep status
$ echo 0x1 > /sys/kernel/debug/dri/0/i915_edp_psr_debug
Source PSR/PanelReplay status: DEEP_SLEEP [0x80310030]
5. Now read panel link status registers again:
$ dpcd_reg read --offset 0x200e --count=1
0x200e: 80
Workaround this by not trusting link status registers after PSR is enabled
until first short pulse interrupt is received.
v2:
- clear link_ok flag on pipe disable
- remove useless comment
- modify intel_dp_needs_link_retrain return statement
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241029122415.1789528-1-jouni.hogander@intel.com
Diffstat (limited to 'tools/perf/scripts/python/gecko.py')
0 files changed, 0 insertions, 0 deletions