Re: [RFC PATCH] drm/i915: PSR regressions on Broadwell

[Brian Norris]

On Mon, Sep 28, 2015 at 10:14:04AM +0300, Jani Nikula wrote:
> On Sat, 26 Sep 2015, Brian Norris  wrote:
> > 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?
> 
> Here's a thought:
> 
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index a04b4dc5ed9b..3a911d4a2308 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -274,6 +274,8 @@ static void hsw_psr_enable_source(struct intel_dp 
> *intel_dp)
>   idle_frames += 4;
>   }
>  
> + idle_frames = clamp(idle_frames, 0, 15);
> +
>   I915_WRITE(EDP_PSR_CTL(dev), val |
>  (IS_BROADWELL(dev) ? 0 : link_entry_time) |
>  max_sleep_time << EDP_PSR_MAX_SLEEP_TIME_SHIFT |

No dice. The VBT actually gives 0, so I just end up with the default 5 +
4 either way.

> We do clamp the VBT value to range 0..15, but then go on to add to it.

But this patch seems quite reasonable anyway.

Acked-by: Brian Norris 

> Otherwise, up to Rodrigo I guess.

Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH] drm/i915: PSR regressions on Broadwell

[Jani Nikula]

On Sat, 26 Sep 2015, Brian Norris  wrote:
> 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?

Here's a thought:

diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index a04b4dc5ed9b..3a911d4a2308 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -274,6 +274,8 @@ static void hsw_psr_enable_source(struct intel_dp *intel_dp)
idle_frames += 4;
}
 
+   idle_frames = clamp(idle_frames, 0, 15);
+
I915_WRITE(EDP_PSR_CTL(dev), val |
   (IS_BROADWELL(dev) ? 0 : link_entry_time) |
   max_sleep_time << EDP_PSR_MAX_SLEEP_TIME_SHIFT |

We do clamp the VBT value to range 0..15, but then go on to add to it.

Otherwise, up to Rodrigo I guess.

BR,
Jani.


>
> 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 
> ---
>  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
>

-- 
Jani Nikula, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH] drm/i915: PSR regressions on Broadwell

[Brian Norris]

On Mon, Sep 28, 2015 at 10:14:04AM +0300, Jani Nikula wrote:
> On Sat, 26 Sep 2015, Brian Norris  wrote:
> > 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?
> 
> Here's a thought:
> 
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index a04b4dc5ed9b..3a911d4a2308 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -274,6 +274,8 @@ static void hsw_psr_enable_source(struct intel_dp 
> *intel_dp)
>   idle_frames += 4;
>   }
>  
> + idle_frames = clamp(idle_frames, 0, 15);
> +
>   I915_WRITE(EDP_PSR_CTL(dev), val |
>  (IS_BROADWELL(dev) ? 0 : link_entry_time) |
>  max_sleep_time << EDP_PSR_MAX_SLEEP_TIME_SHIFT |

No dice. The VBT actually gives 0, so I just end up with the default 5 +
4 either way.

> We do clamp the VBT value to range 0..15, but then go on to add to it.

But this patch seems quite reasonable anyway.

Acked-by: Brian Norris 

> Otherwise, up to Rodrigo I guess.

Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH] drm/i915: PSR regressions on Broadwell

[Jani Nikula]

On Sat, 26 Sep 2015, Brian Norris  wrote:
> 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?

Here's a thought:

diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index a04b4dc5ed9b..3a911d4a2308 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -274,6 +274,8 @@ static void hsw_psr_enable_source(struct intel_dp *intel_dp)
idle_frames += 4;
}
 
+   idle_frames = clamp(idle_frames, 0, 15);
+
I915_WRITE(EDP_PSR_CTL(dev), val |
   (IS_BROADWELL(dev) ? 0 : link_entry_time) |
   max_sleep_time << EDP_PSR_MAX_SLEEP_TIME_SHIFT |

We do clamp the VBT value to range 0..15, but then go on to add to it.

Otherwise, up to Rodrigo I guess.

BR,
Jani.


>
> 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 
> ---
>  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
>

-- 
Jani Nikula, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC PATCH] drm/i915: PSR regressions on Broadwell

[Brian Norris]

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 
---
 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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC PATCH] drm/i915: PSR regressions on Broadwell

[Brian Norris]

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 
---
 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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/