Messages in this thread Patch in this message | | | From | Brian Norris <> | Subject | [RFC PATCH] drm/i915: PSR regressions on Broadwell | Date | Fri, 25 Sep 2015 19:26:13 -0700 |
| |
When using PSR, I see the screen freeze after only a few frames (sometimes a split second; sometimes it seems like practically the first frame). Bisecting led me to commit 3301d4092106 ("drm/i915: PSR: Fix DP_PSR_NO_TRAIN_ON_EXIT logic") in v4.2. This patch is the simplest fix that gets it working again for me, but it's probably wrong.
Random thought: perhaps my panel's DPCD is programmed incorrectly?
Anyway, any tips on fixing this properly?
Seen on Chromebook Pixel 2.
Also required this patch to get PSR properly running on 4.3-rc2:
https://patchwork.freedesktop.org/patch/57698/
Signed-off-by: Brian Norris <briannorris@chromium.org> --- drivers/gpu/drm/i915/intel_psr.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c index 7e335a8546f6..4cd33b76b8a6 100644 --- a/drivers/gpu/drm/i915/intel_psr.c +++ b/drivers/gpu/drm/i915/intel_psr.c @@ -261,7 +261,8 @@ static void hsw_psr_enable_source(struct intel_dp *intel_dp) uint32_t val = 0x0; const uint32_t link_entry_time = EDP_PSR_MIN_LINK_ENTRY_TIME_8_LINES; - if (intel_dp->psr_dpcd[1] & DP_PSR_NO_TRAIN_ON_EXIT) { + if ((intel_dp->psr_dpcd[1] & DP_PSR_NO_TRAIN_ON_EXIT) && + !IS_BROADWELL(dev)) { /* It doesn't mean we shouldn't send TPS patters, so let's send the minimal TP1 possible and skip TP2. */ val |= EDP_PSR_TP1_TIME_100us; -- 2.6.0.rc2.230.g3dd15c0
| |