✓ CI.checkpatch: success for drm/i915/psr: WA for panels stating bad link status after PSR is enabled (rev2)

Patchwork patchwork at emeril.freedesktop.org
Tue Oct 29 13:49:14 UTC 2024


== Series Details ==

Series: drm/i915/psr: WA for panels stating bad link status after PSR is enabled (rev2)
URL   : https://patchwork.freedesktop.org/series/140571/
State : success

== Summary ==

+ KERNEL=/kernel
+ git clone https://gitlab.freedesktop.org/drm/maintainer-tools mt
Cloning into 'mt'...
warning: redirecting to https://gitlab.freedesktop.org/drm/maintainer-tools.git/
+ git -C mt rev-list -n1 origin/master
30ab6715fc09baee6cc14cb3c89ad8858688d474
+ cd /kernel
+ git config --global --add safe.directory /kernel
+ git log -n1
commit 75c2dec6fe2c95eda8b2115514f9828766259b6c
Author: Jouni Högander <jouni.hogander at intel.com>
Date:   Tue Oct 29 14:24:15 2024 +0200

    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 at intel.com>
+ /mt/dim checkpatch 738c18d8599dce736da8b6958f96d2eac08a36ab drm-intel
75c2dec6fe2c drm/i915/psr: WA for panels stating bad link status after PSR is enabled




More information about the Intel-xe mailing list