Re: [Intel-gfx] [PATCH 1/9] drm/i915/psr: Do not activate PSR on frontbuffer flush from fbdev.
On Wed, 2018-01-31 at 22:56 -0800, Rodrigo Vivi wrote:
> On Sat, Jan 27, 2018 at 02:49:15AM +, Dhinakaran Pandiyan wrote:
> > There is no corresponding invalidate call before the buffer is written
> > to, this results in screen freezing sometime after switching to console
> > mode with PSR enabled. Invalidating the front buffer in the fbdev call
> > backs won't work either as some of them are called in atomic contexts and
> > {drrs, fbc, psr}_invalidate all sleep. So don't activate PSR for now.
> >
> > Cc: Rodrigo Vivi
> > Signed-off-by: Dhinakaran Pandiyan
> > ---
> > drivers/gpu/drm/i915/intel_psr.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index e9feffdea899..c12af1118647 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -881,6 +881,9 @@ void intel_psr_flush(struct drm_i915_private *dev_priv,
> > if (!CAN_PSR(dev_priv))
> > return;
> >
> > + if (origin == ORIGIN_DIRTYFB)
> > + return;
> > +
>
> I'd like Paulo to take a look here.
>
> What I'm confused now is who (what fbt bit) is actually blocking PSR to work
> on fbdev.
intel_psr_flush()->intel_psr_exit() does get called as expected, so it's
not the frontbuffer bit that is preventing PSR from exiting. I don't
fully understand why exactly intel_psr_flush() is insufficient (without
psr_invalidate()).
One thing that might be of interest is the gem object has write domain
as zero. I am wondering if we are missing some initialization. But, that
does not explain why the screen freezes only with PSR
>
> And what would be the risks of other corner cases or the risk of this
> not getting psr re-enabled until next reboot...
>
> > mutex_lock(&dev_priv->psr.lock);
> > if (!dev_priv->psr.enabled) {
> > mutex_unlock(&dev_priv->psr.lock);
> > --
> > 2.14.1
> >
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/9] drm/i915/psr: Do not activate PSR on frontbuffer flush from fbdev.
On Sat, Jan 27, 2018 at 02:49:15AM +, Dhinakaran Pandiyan wrote:
> There is no corresponding invalidate call before the buffer is written
> to, this results in screen freezing sometime after switching to console
> mode with PSR enabled. Invalidating the front buffer in the fbdev call
> backs won't work either as some of them are called in atomic contexts and
> {drrs, fbc, psr}_invalidate all sleep. So don't activate PSR for now.
>
> Cc: Rodrigo Vivi
> Signed-off-by: Dhinakaran Pandiyan
> ---
> drivers/gpu/drm/i915/intel_psr.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index e9feffdea899..c12af1118647 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -881,6 +881,9 @@ void intel_psr_flush(struct drm_i915_private *dev_priv,
> if (!CAN_PSR(dev_priv))
> return;
>
> + if (origin == ORIGIN_DIRTYFB)
> + return;
> +
I'd like Paulo to take a look here.
What I'm confused now is who (what fbt bit) is actually blocking PSR to work
on fbdev.
And what would be the risks of other corner cases or the risk of this
not getting psr re-enabled until next reboot...
> mutex_lock(&dev_priv->psr.lock);
> if (!dev_priv->psr.enabled) {
> mutex_unlock(&dev_priv->psr.lock);
> --
> 2.14.1
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/9] drm/i915/psr: Do not activate PSR on frontbuffer flush from fbdev.
There is no corresponding invalidate call before the buffer is written
to, this results in screen freezing sometime after switching to console
mode with PSR enabled. Invalidating the front buffer in the fbdev call
backs won't work either as some of them are called in atomic contexts and
{drrs, fbc, psr}_invalidate all sleep. So don't activate PSR for now.
Cc: Rodrigo Vivi
Signed-off-by: Dhinakaran Pandiyan
---
drivers/gpu/drm/i915/intel_psr.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index e9feffdea899..c12af1118647 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -881,6 +881,9 @@ void intel_psr_flush(struct drm_i915_private *dev_priv,
if (!CAN_PSR(dev_priv))
return;
+ if (origin == ORIGIN_DIRTYFB)
+ return;
+
mutex_lock(&dev_priv->psr.lock);
if (!dev_priv->psr.enabled) {
mutex_unlock(&dev_priv->psr.lock);
--
2.14.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
