From: Daniel Vetter <daniel@ffwll.ch>
To: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
Rodrigo Vivi <rodrigo.vivi@intel.com>
Subject: Re: [PATCH 05/15] drm/i915: Drop schedule_back from psr_exit
Date: Tue, 17 Jun 2014 09:25:12 +0200 [thread overview]
Message-ID: <20140617072512.GP5821@phenom.ffwll.local> (raw)
In-Reply-To: <CABVU7+vxT+jd_=UWUpjFhO1nwxzmTf9RUU7QLqkjK4uHTC9S-g@mail.gmail.com>
On Mon, Jun 16, 2014 at 05:06:06PM -0700, Rodrigo Vivi wrote:
> There were more reasons for disabling it on Baytrail... but you are right..
> disable sequence should be better for those cases.
>
> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Well I should mention that later on we'll split this into psr_invalidate
and psr_flush again. But meanwhile this helps to simplify the code a bit
for the transition. I'll improve the commit message a bit.
-Daniel
>
>
> On Mon, Jun 16, 2014 at 10:51 AM, Daniel Vetter <daniel.vetter@ffwll.ch>
> wrote:
>
> > It doesn't make sense to never again schedule the work, since by the
> > time we might want to re-enable psr the world might have changed and
> > we can do it again.
> >
> > The only exception is when we shut down the pipe, but that's an
> > entirely different thing and needs to be handled in psr_disable.
> >
> > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> > ---
> > drivers/gpu/drm/i915/i915_gem.c | 6 +++---
> > drivers/gpu/drm/i915/intel_display.c | 4 ++--
> > drivers/gpu/drm/i915/intel_dp.c | 7 +++----
> > drivers/gpu/drm/i915/intel_drv.h | 2 +-
> > drivers/gpu/drm/i915/intel_sprite.c | 2 +-
> > 5 files changed, 10 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index 1794a041c13c..f22b4aabb945 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -1395,7 +1395,7 @@ i915_gem_set_domain_ioctl(struct drm_device *dev,
> > void *data,
> > goto unlock;
> > }
> >
> > - intel_edp_psr_exit(dev, true);
> > + intel_edp_psr_exit(dev);
> >
> > /* Try to flush the object off the GPU without holding the lock.
> > * We will repeat the flush holding the lock in the normal manner
> > @@ -1442,7 +1442,7 @@ i915_gem_sw_finish_ioctl(struct drm_device *dev,
> > void *data,
> > if (ret)
> > return ret;
> >
> > - intel_edp_psr_exit(dev, true);
> > + intel_edp_psr_exit(dev);
> >
> > obj = to_intel_bo(drm_gem_object_lookup(dev, file, args->handle));
> > if (&obj->base == NULL) {
> > @@ -4240,7 +4240,7 @@ i915_gem_busy_ioctl(struct drm_device *dev, void
> > *data,
> > if (ret)
> > return ret;
> >
> > - intel_edp_psr_exit(dev, true);
> > + intel_edp_psr_exit(dev);
> >
> > obj = to_intel_bo(drm_gem_object_lookup(dev, file, args->handle));
> > if (&obj->base == NULL) {
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index c27dadebd0dc..6f2588c95248 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -8823,7 +8823,7 @@ void intel_mark_fb_busy(struct drm_i915_gem_object
> > *obj,
> > struct drm_device *dev = obj->base.dev;
> > struct drm_crtc *crtc;
> >
> > - intel_edp_psr_exit(dev, true);
> > + intel_edp_psr_exit(dev);
> >
> > if (!i915.powersave)
> > return;
> > @@ -9292,7 +9292,7 @@ static int intel_crtc_page_flip(struct drm_crtc
> > *crtc,
> > return -ENOMEM;
> >
> > /* Exit PSR early in page flip */
> > - intel_edp_psr_exit(dev, true);
> > + intel_edp_psr_exit(dev);
> >
> > work->event = event;
> > work->crtc = crtc;
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 4ab4757fb53d..c7d625040e3d 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -1899,7 +1899,7 @@ static void intel_edp_psr_inactivate(struct
> > drm_device *dev)
> > & ~EDP_PSR_ENABLE);
> > }
> >
> > -void intel_edp_psr_exit(struct drm_device *dev, bool schedule_back)
> > +void intel_edp_psr_exit(struct drm_device *dev)
> > {
> > struct drm_i915_private *dev_priv = dev->dev_private;
> >
> > @@ -1911,9 +1911,8 @@ void intel_edp_psr_exit(struct drm_device *dev, bool
> > schedule_back)
> > if (dev_priv->psr.active)
> > intel_edp_psr_inactivate(dev);
> >
> > - if (schedule_back)
> > - schedule_delayed_work(&dev_priv->psr.work,
> > - msecs_to_jiffies(100));
> > + schedule_delayed_work(&dev_priv->psr.work,
> > + msecs_to_jiffies(100));
> > }
> >
> > void intel_edp_psr_init(struct drm_device *dev)
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 87e83c315c4b..1d45629a6483 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -829,7 +829,7 @@ void intel_edp_panel_off(struct intel_dp *intel_dp);
> > void intel_edp_psr_enable(struct intel_dp *intel_dp);
> > void intel_edp_psr_disable(struct intel_dp *intel_dp);
> > void intel_dp_set_drrs_state(struct drm_device *dev, int refresh_rate);
> > -void intel_edp_psr_exit(struct drm_device *dev, bool schedule_back);
> > +void intel_edp_psr_exit(struct drm_device *dev);
> > void intel_edp_psr_init(struct drm_device *dev);
> >
> >
> > diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> > b/drivers/gpu/drm/i915/intel_sprite.c
> > index 2a211c64ec8d..9038e2ab73c8 100644
> > --- a/drivers/gpu/drm/i915/intel_sprite.c
> > +++ b/drivers/gpu/drm/i915/intel_sprite.c
> > @@ -1051,7 +1051,7 @@ intel_update_plane(struct drm_plane *plane, struct
> > drm_crtc *crtc,
> > mutex_unlock(&dev->struct_mutex);
> > }
> >
> > - intel_edp_psr_exit(dev, true);
> > + intel_edp_psr_exit(dev);
> >
> > return 0;
> > }
> > --
> > 2.0.0
> >
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >
>
>
>
> --
> Rodrigo Vivi
> Blog: http://blog.vivi.eng.br
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
next prev parent reply other threads:[~2014-06-17 7:25 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-16 17:51 [PATCH 00/15] Accurate frontbuffer tracking and psr conversion Daniel Vetter
2014-06-16 17:51 ` [PATCH 01/15] drm/i915: Add missing statics to recent psr functions Daniel Vetter
2014-06-16 23:57 ` Rodrigo Vivi
2014-06-17 8:22 ` Daniel Vetter
2014-06-16 17:51 ` [PATCH 02/15] drm/i915: Drop unecessary complexity from psr_inactivate Daniel Vetter
2014-06-16 23:58 ` Rodrigo Vivi
2014-06-16 17:51 ` [PATCH 03/15] drm/i915: Ditch intel_edp_psr_update Daniel Vetter
2014-06-17 0:00 ` Rodrigo Vivi
2014-06-16 17:51 ` [PATCH 04/15] drm/i915: Run psr_setup unconditionally Daniel Vetter
2014-06-17 0:03 ` Rodrigo Vivi
2014-06-17 6:43 ` Chris Wilson
2014-06-17 7:23 ` Daniel Vetter
2014-06-17 8:26 ` Daniel Vetter
2014-06-16 17:51 ` [PATCH 05/15] drm/i915: Drop schedule_back from psr_exit Daniel Vetter
2014-06-17 0:06 ` Rodrigo Vivi
2014-06-17 7:25 ` Daniel Vetter [this message]
2014-06-16 17:51 ` [PATCH 06/15] drm/i915: Add a FIXME about drrs/psr interactions Daniel Vetter
2014-06-16 17:51 ` [PATCH 07/15] drm/i915: Track the psr dp connector in dev_priv->psr.enabled Daniel Vetter
2014-06-17 0:10 ` Rodrigo Vivi
2014-06-17 7:26 ` Daniel Vetter
2014-06-16 17:51 ` [PATCH 08/15] drm/i915: Don't try to disable psr harder from the work item Daniel Vetter
2014-06-17 0:20 ` Rodrigo Vivi
2014-06-17 7:29 ` Daniel Vetter
2014-06-16 17:51 ` [PATCH 09/15] drm/i915: Lock down psr sw/hw state tracking Daniel Vetter
2014-06-16 17:51 ` [PATCH 10/15] drm/i915: More checks for psr.enabled Daniel Vetter
2014-06-16 17:51 ` [PATCH 11/15] drm/i915: Add locking to psr code Daniel Vetter
2014-06-16 17:51 ` [PATCH 12/15] drm/i915: Introduce accurate frontbuffer tracking Daniel Vetter
2014-06-16 17:51 ` [PATCH 13/15] drm/i915: Use new frontbuffer bits to increase pll clock Daniel Vetter
2014-06-16 17:51 ` [PATCH 14/15] drm/i915: Track frontbuffer invalidation/flushing Daniel Vetter
2014-06-17 6:41 ` Chris Wilson
2014-06-17 7:32 ` Daniel Vetter
2014-06-17 7:36 ` Chris Wilson
2014-06-17 9:01 ` Daniel Vetter
2014-06-17 6:46 ` Chris Wilson
2014-06-17 7:33 ` Daniel Vetter
2014-06-17 6:49 ` Chris Wilson
2014-06-17 7:36 ` Daniel Vetter
2014-06-17 6:50 ` Chris Wilson
2014-06-17 7:37 ` Daniel Vetter
2014-06-17 7:40 ` Chris Wilson
2014-06-17 7:42 ` Chris Wilson
2014-06-17 6:52 ` Chris Wilson
2014-06-17 7:39 ` Daniel Vetter
2014-06-17 6:54 ` Chris Wilson
2014-06-17 7:45 ` Daniel Vetter
2014-06-17 7:53 ` Chris Wilson
2014-06-17 9:17 ` Daniel Vetter
2014-06-17 6:57 ` Chris Wilson
2014-06-17 7:48 ` Daniel Vetter
2014-06-17 7:55 ` Chris Wilson
2014-06-17 7:00 ` Chris Wilson
2014-06-17 7:52 ` Daniel Vetter
2014-06-17 8:10 ` Chris Wilson
2014-06-17 9:33 ` Daniel Vetter
2014-06-17 9:42 ` Chris Wilson
2014-06-17 9:54 ` Daniel Vetter
2014-06-17 10:00 ` Chris Wilson
2014-06-16 17:51 ` [PATCH 15/15] drm/i915: Fix up PSR frontbuffer tracking Daniel Vetter
2014-06-17 7:02 ` Chris Wilson
2014-06-17 8:06 ` Daniel Vetter
2014-06-17 7:07 ` Chris Wilson
2014-06-17 8:08 ` Daniel Vetter
2014-06-16 19:37 ` [PATCH 00/15] Accurate frontbuffer tracking and psr conversion Chris Wilson
2014-06-16 20:37 ` Daniel Vetter
2014-06-17 7:09 ` Chris Wilson
2014-06-17 9:30 ` Daniel Vetter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140617072512.GP5821@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=daniel.vetter@ffwll.ch \
--cc=intel-gfx@lists.freedesktop.org \
--cc=rodrigo.vivi@gmail.com \
--cc=rodrigo.vivi@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox