* [PATCH v4 1/5] drm/i915: create a prepare step for primary planes updates
@ 2014-10-24 13:51 Gustavo Padovan
2014-10-24 13:51 ` [PATCH v4 2/5] drm/i915: create a prepare phase for sprite plane updates Gustavo Padovan
` (3 more replies)
0 siblings, 4 replies; 24+ messages in thread
From: Gustavo Padovan @ 2014-10-24 13:51 UTC (permalink / raw)
To: intel-gfx; +Cc: Gustavo Padovan, dri-devel
From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Take out the pin_fb code so commit phase can't fail anymore.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/i915/intel_display.c | 35 ++++++++++++++++++++++++++---------
1 file changed, 26 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 7d891e5..8530401 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11660,20 +11660,16 @@ intel_check_primary_plane(struct drm_plane *plane,
}
static int
-intel_commit_primary_plane(struct drm_plane *plane,
- struct intel_plane_state *state)
+intel_prepare_primary_plane(struct drm_plane *plane,
+ struct intel_plane_state *state)
{
struct drm_crtc *crtc = state->crtc;
struct drm_framebuffer *fb = state->fb;
struct drm_device *dev = crtc->dev;
- struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
enum pipe pipe = intel_crtc->pipe;
- struct drm_framebuffer *old_fb = plane->fb;
struct drm_i915_gem_object *obj = intel_fb_obj(fb);
struct drm_i915_gem_object *old_obj = intel_fb_obj(plane->fb);
- struct intel_plane *intel_plane = to_intel_plane(plane);
- struct drm_rect *src = &state->src;
int ret;
intel_crtc_wait_for_pending_flips(crtc);
@@ -11683,7 +11679,7 @@ intel_commit_primary_plane(struct drm_plane *plane,
return -EBUSY;
}
- if (plane->fb != fb) {
+ if (old_obj != obj) {
mutex_lock(&dev->struct_mutex);
ret = intel_pin_and_fence_fb_obj(dev, obj, NULL);
if (ret == 0)
@@ -11696,6 +11692,25 @@ intel_commit_primary_plane(struct drm_plane *plane,
}
}
+ return 0;
+}
+
+static void
+intel_commit_primary_plane(struct drm_plane *plane,
+ struct intel_plane_state *state)
+{
+ struct drm_crtc *crtc = state->crtc;
+ struct drm_framebuffer *fb = state->fb;
+ struct drm_device *dev = crtc->dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ enum pipe pipe = intel_crtc->pipe;
+ struct drm_framebuffer *old_fb = plane->fb;
+ struct drm_i915_gem_object *obj = intel_fb_obj(fb);
+ struct drm_i915_gem_object *old_obj = intel_fb_obj(plane->fb);
+ struct intel_plane *intel_plane = to_intel_plane(plane);
+ struct drm_rect *src = &state->src;
+
crtc->primary->fb = fb;
crtc->x = src->x1;
crtc->y = src->y1;
@@ -11772,8 +11787,6 @@ intel_commit_primary_plane(struct drm_plane *plane,
intel_unpin_fb_obj(old_obj);
mutex_unlock(&dev->struct_mutex);
}
-
- return 0;
}
static int
@@ -11814,6 +11827,10 @@ intel_primary_plane_setplane(struct drm_plane *plane, struct drm_crtc *crtc,
if (ret)
return ret;
+ ret = intel_prepare_primary_plane(plane, &state);
+ if (ret)
+ return ret;
+
intel_commit_primary_plane(plane, &state);
return 0;
--
1.9.3
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 24+ messages in thread* [PATCH v4 2/5] drm/i915: create a prepare phase for sprite plane updates 2014-10-24 13:51 [PATCH v4 1/5] drm/i915: create a prepare step for primary planes updates Gustavo Padovan @ 2014-10-24 13:51 ` Gustavo Padovan 2014-10-30 13:32 ` Paulo Zanoni 2014-10-24 13:51 ` [PATCH v4 3/5] drm/i915: use intel_fb_obj() macros to assign gem objects Gustavo Padovan ` (2 subsequent siblings) 3 siblings, 1 reply; 24+ messages in thread From: Gustavo Padovan @ 2014-10-24 13:51 UTC (permalink / raw) To: intel-gfx; +Cc: Gustavo Padovan, dri-devel From: Gustavo Padovan <gustavo.padovan@collabora.co.uk> take out pin_fb code so the commit phase can't fail anymore. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> --- drivers/gpu/drm/i915/intel_sprite.c | 63 +++++++++++++++++++++++-------------- 1 file changed, 40 insertions(+), 23 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c index 2c060ad..3631b0e 100644 --- a/drivers/gpu/drm/i915/intel_sprite.c +++ b/drivers/gpu/drm/i915/intel_sprite.c @@ -1192,34 +1192,18 @@ intel_check_sprite_plane(struct drm_plane *plane, } static int -intel_commit_sprite_plane(struct drm_plane *plane, - struct intel_plane_state *state) +intel_prepare_sprite_plane(struct drm_plane *plane, + struct intel_plane_state *state) { struct drm_device *dev = plane->dev; struct drm_crtc *crtc = state->crtc; struct intel_crtc *intel_crtc = to_intel_crtc(crtc); - struct intel_plane *intel_plane = to_intel_plane(plane); enum pipe pipe = intel_crtc->pipe; struct drm_framebuffer *fb = state->fb; - struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb); - struct drm_i915_gem_object *obj = intel_fb->obj; - struct drm_i915_gem_object *old_obj = intel_plane->obj; - int crtc_x, crtc_y; - unsigned int crtc_w, crtc_h; - uint32_t src_x, src_y, src_w, src_h; - struct drm_rect *dst = &state->dst; - const struct drm_rect *clip = &state->clip; - bool primary_enabled; + struct drm_i915_gem_object *obj = intel_fb_obj(fb); + struct drm_i915_gem_object *old_obj = intel_fb_obj(plane->fb); int ret; - /* - * If the sprite is completely covering the primary plane, - * we can disable the primary and save power. - */ - primary_enabled = !drm_rect_equals(dst, clip) || colorkey_enabled(intel_plane); - WARN_ON(!primary_enabled && !state->visible && intel_crtc->active); - - if (old_obj != obj) { mutex_lock(&dev->struct_mutex); @@ -1238,6 +1222,36 @@ intel_commit_sprite_plane(struct drm_plane *plane, return ret; } + return 0; +} + +static void +intel_commit_sprite_plane(struct drm_plane *plane, + struct intel_plane_state *state) +{ + struct drm_device *dev = plane->dev; + struct drm_crtc *crtc = state->crtc; + struct intel_crtc *intel_crtc = to_intel_crtc(crtc); + struct intel_plane *intel_plane = to_intel_plane(plane); + enum pipe pipe = intel_crtc->pipe; + struct drm_framebuffer *fb = state->fb; + struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb); + struct drm_i915_gem_object *obj = intel_fb->obj; + struct drm_i915_gem_object *old_obj = intel_plane->obj; + int crtc_x, crtc_y; + unsigned int crtc_w, crtc_h; + uint32_t src_x, src_y, src_w, src_h; + struct drm_rect *dst = &state->dst; + const struct drm_rect *clip = &state->clip; + bool primary_enabled; + + /* + * If the sprite is completely covering the primary plane, + * we can disable the primary and save power. + */ + primary_enabled = !drm_rect_equals(dst, clip) || colorkey_enabled(intel_plane); + WARN_ON(!primary_enabled && !state->visible && intel_crtc->active); + intel_plane->crtc_x = state->orig_dst.x1; intel_plane->crtc_y = state->orig_dst.y1; intel_plane->crtc_w = drm_rect_width(&state->orig_dst); @@ -1298,8 +1312,6 @@ intel_commit_sprite_plane(struct drm_plane *plane, intel_unpin_fb_obj(old_obj); mutex_unlock(&dev->struct_mutex); } - - return 0; } static int @@ -1339,7 +1351,12 @@ intel_update_plane(struct drm_plane *plane, struct drm_crtc *crtc, if (ret) return ret; - return intel_commit_sprite_plane(plane, &state); + ret = intel_prepare_sprite_plane(plane, &state); + if (ret) + return ret; + + intel_commit_sprite_plane(plane, &state); + return 0; } static int -- 1.9.3 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: [PATCH v4 2/5] drm/i915: create a prepare phase for sprite plane updates 2014-10-24 13:51 ` [PATCH v4 2/5] drm/i915: create a prepare phase for sprite plane updates Gustavo Padovan @ 2014-10-30 13:32 ` Paulo Zanoni 2014-10-30 14:08 ` [Intel-gfx] " Imre Deak 2014-10-30 14:34 ` Ville Syrjälä 0 siblings, 2 replies; 24+ messages in thread From: Paulo Zanoni @ 2014-10-30 13:32 UTC (permalink / raw) To: Gustavo Padovan Cc: Intel Graphics Development, Gustavo Padovan, DRI Development 2014-10-24 11:51 GMT-02:00 Gustavo Padovan <gustavo@padovan.org>: > From: Gustavo Padovan <gustavo.padovan@collabora.co.uk> > > take out pin_fb code so the commit phase can't fail anymore. > According to my bisection results, this is the first bad commit of https://bugs.freedesktop.org/show_bug.cgi?id=85634. > Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> > Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> > --- > drivers/gpu/drm/i915/intel_sprite.c | 63 +++++++++++++++++++++++-------------- > 1 file changed, 40 insertions(+), 23 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c > index 2c060ad..3631b0e 100644 > --- a/drivers/gpu/drm/i915/intel_sprite.c > +++ b/drivers/gpu/drm/i915/intel_sprite.c > @@ -1192,34 +1192,18 @@ intel_check_sprite_plane(struct drm_plane *plane, > } > > static int > -intel_commit_sprite_plane(struct drm_plane *plane, > - struct intel_plane_state *state) > +intel_prepare_sprite_plane(struct drm_plane *plane, > + struct intel_plane_state *state) > { > struct drm_device *dev = plane->dev; > struct drm_crtc *crtc = state->crtc; > struct intel_crtc *intel_crtc = to_intel_crtc(crtc); > - struct intel_plane *intel_plane = to_intel_plane(plane); > enum pipe pipe = intel_crtc->pipe; > struct drm_framebuffer *fb = state->fb; > - struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb); > - struct drm_i915_gem_object *obj = intel_fb->obj; > - struct drm_i915_gem_object *old_obj = intel_plane->obj; > - int crtc_x, crtc_y; > - unsigned int crtc_w, crtc_h; > - uint32_t src_x, src_y, src_w, src_h; > - struct drm_rect *dst = &state->dst; > - const struct drm_rect *clip = &state->clip; > - bool primary_enabled; > + struct drm_i915_gem_object *obj = intel_fb_obj(fb); > + struct drm_i915_gem_object *old_obj = intel_fb_obj(plane->fb); > int ret; > > - /* > - * If the sprite is completely covering the primary plane, > - * we can disable the primary and save power. > - */ > - primary_enabled = !drm_rect_equals(dst, clip) || colorkey_enabled(intel_plane); > - WARN_ON(!primary_enabled && !state->visible && intel_crtc->active); > - > - > if (old_obj != obj) { > mutex_lock(&dev->struct_mutex); > > @@ -1238,6 +1222,36 @@ intel_commit_sprite_plane(struct drm_plane *plane, > return ret; > } > > + return 0; > +} > + > +static void > +intel_commit_sprite_plane(struct drm_plane *plane, > + struct intel_plane_state *state) > +{ > + struct drm_device *dev = plane->dev; > + struct drm_crtc *crtc = state->crtc; > + struct intel_crtc *intel_crtc = to_intel_crtc(crtc); > + struct intel_plane *intel_plane = to_intel_plane(plane); > + enum pipe pipe = intel_crtc->pipe; > + struct drm_framebuffer *fb = state->fb; > + struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb); > + struct drm_i915_gem_object *obj = intel_fb->obj; > + struct drm_i915_gem_object *old_obj = intel_plane->obj; > + int crtc_x, crtc_y; > + unsigned int crtc_w, crtc_h; > + uint32_t src_x, src_y, src_w, src_h; > + struct drm_rect *dst = &state->dst; > + const struct drm_rect *clip = &state->clip; > + bool primary_enabled; > + > + /* > + * If the sprite is completely covering the primary plane, > + * we can disable the primary and save power. > + */ > + primary_enabled = !drm_rect_equals(dst, clip) || colorkey_enabled(intel_plane); > + WARN_ON(!primary_enabled && !state->visible && intel_crtc->active); > + > intel_plane->crtc_x = state->orig_dst.x1; > intel_plane->crtc_y = state->orig_dst.y1; > intel_plane->crtc_w = drm_rect_width(&state->orig_dst); > @@ -1298,8 +1312,6 @@ intel_commit_sprite_plane(struct drm_plane *plane, > intel_unpin_fb_obj(old_obj); > mutex_unlock(&dev->struct_mutex); > } > - > - return 0; > } > > static int > @@ -1339,7 +1351,12 @@ intel_update_plane(struct drm_plane *plane, struct drm_crtc *crtc, > if (ret) > return ret; > > - return intel_commit_sprite_plane(plane, &state); > + ret = intel_prepare_sprite_plane(plane, &state); > + if (ret) > + return ret; > + > + intel_commit_sprite_plane(plane, &state); > + return 0; > } > > static int > -- > 1.9.3 > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Paulo Zanoni _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Intel-gfx] [PATCH v4 2/5] drm/i915: create a prepare phase for sprite plane updates 2014-10-30 13:32 ` Paulo Zanoni @ 2014-10-30 14:08 ` Imre Deak 2014-10-30 14:34 ` Ville Syrjälä 1 sibling, 0 replies; 24+ messages in thread From: Imre Deak @ 2014-10-30 14:08 UTC (permalink / raw) To: Paulo Zanoni; +Cc: Intel Graphics Development, Gustavo Padovan, DRI Development On Thu, 2014-10-30 at 11:32 -0200, Paulo Zanoni wrote: > 2014-10-24 11:51 GMT-02:00 Gustavo Padovan <gustavo@padovan.org>: > > From: Gustavo Padovan <gustavo.padovan@collabora.co.uk> > > > > take out pin_fb code so the commit phase can't fail anymore. > > > > According to my bisection results, this is the first bad commit of > https://bugs.freedesktop.org/show_bug.cgi?id=85634. I saw the same issue, when checking #82939. AFAICS when disabling the crtc intel_plane->obj will be set to NULL and the object will be unpinned, but plane->fb remains set. Next if drm_set_plane with the same fb is called intel_prepare_sprite_plane() won't pin the object since it sees that same fb is still set, but sets intel_plane->obj. Next if drm_set_plane called with a NULL fb, it will try unpin the object, and the unbalanced refcount throws a WARN. The following got rid of the problem for me: diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c index 8b80d68..36762b5 100644 --- a/drivers/gpu/drm/i915/intel_sprite.c +++ b/drivers/gpu/drm/i915/intel_sprite.c @@ -1198,9 +1198,10 @@ intel_prepare_sprite_plane(struct drm_plane *plane, struct drm_crtc *crtc = state->crtc; struct intel_crtc *intel_crtc = to_intel_crtc(crtc); enum pipe pipe = intel_crtc->pipe; + struct intel_plane *intel_plane = to_intel_plane(plane); struct drm_framebuffer *fb = state->fb; struct drm_i915_gem_object *obj = intel_fb_obj(fb); - struct drm_i915_gem_object *old_obj = intel_fb_obj(plane->fb); + struct drm_i915_gem_object *old_obj = intel_plane->obj; int ret; if (old_obj != obj) { > > > > Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> > > Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> > > --- > > drivers/gpu/drm/i915/intel_sprite.c | 63 +++++++++++++++++++++++-------------- > > 1 file changed, 40 insertions(+), 23 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c > > index 2c060ad..3631b0e 100644 > > --- a/drivers/gpu/drm/i915/intel_sprite.c > > +++ b/drivers/gpu/drm/i915/intel_sprite.c > > @@ -1192,34 +1192,18 @@ intel_check_sprite_plane(struct drm_plane *plane, > > } > > > > static int > > -intel_commit_sprite_plane(struct drm_plane *plane, > > - struct intel_plane_state *state) > > +intel_prepare_sprite_plane(struct drm_plane *plane, > > + struct intel_plane_state *state) > > { > > struct drm_device *dev = plane->dev; > > struct drm_crtc *crtc = state->crtc; > > struct intel_crtc *intel_crtc = to_intel_crtc(crtc); > > - struct intel_plane *intel_plane = to_intel_plane(plane); > > enum pipe pipe = intel_crtc->pipe; > > struct drm_framebuffer *fb = state->fb; > > - struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb); > > - struct drm_i915_gem_object *obj = intel_fb->obj; > > - struct drm_i915_gem_object *old_obj = intel_plane->obj; > > - int crtc_x, crtc_y; > > - unsigned int crtc_w, crtc_h; > > - uint32_t src_x, src_y, src_w, src_h; > > - struct drm_rect *dst = &state->dst; > > - const struct drm_rect *clip = &state->clip; > > - bool primary_enabled; > > + struct drm_i915_gem_object *obj = intel_fb_obj(fb); > > + struct drm_i915_gem_object *old_obj = intel_fb_obj(plane->fb); > > int ret; > > > > - /* > > - * If the sprite is completely covering the primary plane, > > - * we can disable the primary and save power. > > - */ > > - primary_enabled = !drm_rect_equals(dst, clip) || colorkey_enabled(intel_plane); > > - WARN_ON(!primary_enabled && !state->visible && intel_crtc->active); > > - > > - > > if (old_obj != obj) { > > mutex_lock(&dev->struct_mutex); > > > > @@ -1238,6 +1222,36 @@ intel_commit_sprite_plane(struct drm_plane *plane, > > return ret; > > } > > > > + return 0; > > +} > > + > > +static void > > +intel_commit_sprite_plane(struct drm_plane *plane, > > + struct intel_plane_state *state) > > +{ > > + struct drm_device *dev = plane->dev; > > + struct drm_crtc *crtc = state->crtc; > > + struct intel_crtc *intel_crtc = to_intel_crtc(crtc); > > + struct intel_plane *intel_plane = to_intel_plane(plane); > > + enum pipe pipe = intel_crtc->pipe; > > + struct drm_framebuffer *fb = state->fb; > > + struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb); > > + struct drm_i915_gem_object *obj = intel_fb->obj; > > + struct drm_i915_gem_object *old_obj = intel_plane->obj; > > + int crtc_x, crtc_y; > > + unsigned int crtc_w, crtc_h; > > + uint32_t src_x, src_y, src_w, src_h; > > + struct drm_rect *dst = &state->dst; > > + const struct drm_rect *clip = &state->clip; > > + bool primary_enabled; > > + > > + /* > > + * If the sprite is completely covering the primary plane, > > + * we can disable the primary and save power. > > + */ > > + primary_enabled = !drm_rect_equals(dst, clip) || colorkey_enabled(intel_plane); > > + WARN_ON(!primary_enabled && !state->visible && intel_crtc->active); > > + > > intel_plane->crtc_x = state->orig_dst.x1; > > intel_plane->crtc_y = state->orig_dst.y1; > > intel_plane->crtc_w = drm_rect_width(&state->orig_dst); > > @@ -1298,8 +1312,6 @@ intel_commit_sprite_plane(struct drm_plane *plane, > > intel_unpin_fb_obj(old_obj); > > mutex_unlock(&dev->struct_mutex); > > } > > - > > - return 0; > > } > > > > static int > > @@ -1339,7 +1351,12 @@ intel_update_plane(struct drm_plane *plane, struct drm_crtc *crtc, > > if (ret) > > return ret; > > > > - return intel_commit_sprite_plane(plane, &state); > > + ret = intel_prepare_sprite_plane(plane, &state); > > + if (ret) > > + return ret; > > + > > + intel_commit_sprite_plane(plane, &state); > > + return 0; > > } > > > > static int > > -- > > 1.9.3 > > > > _______________________________________________ > > Intel-gfx mailing list > > Intel-gfx@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/intel-gfx > > > _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: [Intel-gfx] [PATCH v4 2/5] drm/i915: create a prepare phase for sprite plane updates 2014-10-30 13:32 ` Paulo Zanoni 2014-10-30 14:08 ` [Intel-gfx] " Imre Deak @ 2014-10-30 14:34 ` Ville Syrjälä 2014-10-30 18:02 ` [PATCH] drm/i915: use the correct obj when preparing the sprite plane Paulo Zanoni 1 sibling, 1 reply; 24+ messages in thread From: Ville Syrjälä @ 2014-10-30 14:34 UTC (permalink / raw) To: Paulo Zanoni; +Cc: Intel Graphics Development, Gustavo Padovan, DRI Development On Thu, Oct 30, 2014 at 11:32:42AM -0200, Paulo Zanoni wrote: > 2014-10-24 11:51 GMT-02:00 Gustavo Padovan <gustavo@padovan.org>: > > From: Gustavo Padovan <gustavo.padovan@collabora.co.uk> > > > > take out pin_fb code so the commit phase can't fail anymore. > > > > According to my bisection results, this is the first bad commit of > https://bugs.freedesktop.org/show_bug.cgi?id=85634. > > > > Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> > > Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> > > --- > > drivers/gpu/drm/i915/intel_sprite.c | 63 +++++++++++++++++++++++-------------- > > 1 file changed, 40 insertions(+), 23 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c > > index 2c060ad..3631b0e 100644 > > --- a/drivers/gpu/drm/i915/intel_sprite.c > > +++ b/drivers/gpu/drm/i915/intel_sprite.c > > @@ -1192,34 +1192,18 @@ intel_check_sprite_plane(struct drm_plane *plane, > > } > > > > static int > > -intel_commit_sprite_plane(struct drm_plane *plane, > > - struct intel_plane_state *state) > > +intel_prepare_sprite_plane(struct drm_plane *plane, > > + struct intel_plane_state *state) <snip> > > - struct drm_i915_gem_object *old_obj = intel_plane->obj; > > + struct drm_i915_gem_object *old_obj = intel_fb_obj(plane->fb); I think this change is the culprit here. The problem is that during a modeset we call intel_plane_disable()->intel_disable_plane() (yeah, yeah the names suck big time :) which will unpin the current buffer and clear intel_plane->obj, but plane->fb will still be set, so the next time .update_plane() is called it will think the buffer was already pinned, and not attempt to pin it again. So just using intel_plane->obj to figure out the old obj should fix it. But my plan sort of was that even if userspace "enables" a plane with the crtc off, we'd still pin the buffer. Then we can be more sure that when the crtc does get enabled the plane can actually be enabled as well (ie. the pinning can't fail at that point anymore). So if we follow that design I think we need to split intel_disable_plane() into two parts, one which just does the plane disable, and the second part just does unpinning. And then we need to just call the non-unpin variant from intel_plane_disable() so that we don't unpin the buffer during crtc disable. And then we should also kill intel_plane->obj. > > int ret; > > > > - /* > > - * If the sprite is completely covering the primary plane, > > - * we can disable the primary and save power. > > - */ > > - primary_enabled = !drm_rect_equals(dst, clip) || colorkey_enabled(intel_plane); > > - WARN_ON(!primary_enabled && !state->visible && intel_crtc->active); > > - > > - > > if (old_obj != obj) { > > mutex_lock(&dev->struct_mutex); > > > > @@ -1238,6 +1222,36 @@ intel_commit_sprite_plane(struct drm_plane *plane, > > return ret; > > } > > > > + return 0; > > +} > > + > > +static void > > +intel_commit_sprite_plane(struct drm_plane *plane, > > + struct intel_plane_state *state) > > +{ > > + struct drm_device *dev = plane->dev; > > + struct drm_crtc *crtc = state->crtc; > > + struct intel_crtc *intel_crtc = to_intel_crtc(crtc); > > + struct intel_plane *intel_plane = to_intel_plane(plane); > > + enum pipe pipe = intel_crtc->pipe; > > + struct drm_framebuffer *fb = state->fb; > > + struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb); > > + struct drm_i915_gem_object *obj = intel_fb->obj; > > + struct drm_i915_gem_object *old_obj = intel_plane->obj; > > + int crtc_x, crtc_y; > > + unsigned int crtc_w, crtc_h; > > + uint32_t src_x, src_y, src_w, src_h; > > + struct drm_rect *dst = &state->dst; > > + const struct drm_rect *clip = &state->clip; > > + bool primary_enabled; > > + > > + /* > > + * If the sprite is completely covering the primary plane, > > + * we can disable the primary and save power. > > + */ > > + primary_enabled = !drm_rect_equals(dst, clip) || colorkey_enabled(intel_plane); > > + WARN_ON(!primary_enabled && !state->visible && intel_crtc->active); > > + > > intel_plane->crtc_x = state->orig_dst.x1; > > intel_plane->crtc_y = state->orig_dst.y1; > > intel_plane->crtc_w = drm_rect_width(&state->orig_dst); > > @@ -1298,8 +1312,6 @@ intel_commit_sprite_plane(struct drm_plane *plane, > > intel_unpin_fb_obj(old_obj); > > mutex_unlock(&dev->struct_mutex); > > } > > - > > - return 0; > > } > > > > static int > > @@ -1339,7 +1351,12 @@ intel_update_plane(struct drm_plane *plane, struct drm_crtc *crtc, > > if (ret) > > return ret; > > > > - return intel_commit_sprite_plane(plane, &state); > > + ret = intel_prepare_sprite_plane(plane, &state); > > + if (ret) > > + return ret; > > + > > + intel_commit_sprite_plane(plane, &state); > > + return 0; > > } > > > > static int > > -- > > 1.9.3 > > > > _______________________________________________ > > Intel-gfx mailing list > > Intel-gfx@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/intel-gfx > > > > -- > Paulo Zanoni > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ville Syrjälä Intel OTC _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH] drm/i915: use the correct obj when preparing the sprite plane 2014-10-30 14:34 ` Ville Syrjälä @ 2014-10-30 18:02 ` Paulo Zanoni 2014-10-30 19:10 ` Ville Syrjälä 0 siblings, 1 reply; 24+ messages in thread From: Paulo Zanoni @ 2014-10-30 18:02 UTC (permalink / raw) To: intel-gfx; +Cc: Gustavo Padovan, Paulo Zanoni From: Paulo Zanoni <paulo.r.zanoni@intel.com> Commit "drm/i915: create a prepare phase for sprite plane updates" changed the old_obj pointer we use when committing sprite planes, which caused a WARN() and a BUG() to be triggered. This patch should revert the code back to the previous behavior, fixing the regression. Regression introduced by: commit ec82cb793c9224e0692eed904f43490cf70e8258 Author: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Date: Fri Oct 24 14:51:32 2014 +0100 drm/i915: create a prepare phase for sprite plane updates Credits to Imre Deak for pointing out the exact lines that were wrong. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85634 Testcase: igt/pm_rpm/legacy-planes Testcase: igt/pm_rpm/legacy-planes-dpms Testcase: igt/pm_rpm/universal-planes Testcase: igt/pm_rpm/universal-planes-dpms Credits-to: Imre Deak <imre.deak@intel.com> Cc: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> --- drivers/gpu/drm/i915/intel_sprite.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c index 8b80d68..1c874309 100644 --- a/drivers/gpu/drm/i915/intel_sprite.c +++ b/drivers/gpu/drm/i915/intel_sprite.c @@ -1197,10 +1197,11 @@ intel_prepare_sprite_plane(struct drm_plane *plane, struct drm_device *dev = plane->dev; struct drm_crtc *crtc = state->crtc; struct intel_crtc *intel_crtc = to_intel_crtc(crtc); + struct intel_plane *intel_plane = to_intel_plane(plane); enum pipe pipe = intel_crtc->pipe; struct drm_framebuffer *fb = state->fb; struct drm_i915_gem_object *obj = intel_fb_obj(fb); - struct drm_i915_gem_object *old_obj = intel_fb_obj(plane->fb); + struct drm_i915_gem_object *old_obj = intel_plane->obj; int ret; if (old_obj != obj) { -- 2.1.1 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: [PATCH] drm/i915: use the correct obj when preparing the sprite plane 2014-10-30 18:02 ` [PATCH] drm/i915: use the correct obj when preparing the sprite plane Paulo Zanoni @ 2014-10-30 19:10 ` Ville Syrjälä 2014-10-30 19:33 ` Paulo Zanoni 2014-11-10 16:47 ` Paulo Zanoni 0 siblings, 2 replies; 24+ messages in thread From: Ville Syrjälä @ 2014-10-30 19:10 UTC (permalink / raw) To: Paulo Zanoni; +Cc: intel-gfx, Gustavo Padovan, Paulo Zanoni On Thu, Oct 30, 2014 at 04:02:01PM -0200, Paulo Zanoni wrote: > From: Paulo Zanoni <paulo.r.zanoni@intel.com> > > Commit "drm/i915: create a prepare phase for sprite plane updates" > changed the old_obj pointer we use when committing sprite planes, > which caused a WARN() and a BUG() to be triggered. This patch should > revert the code back to the previous behavior, fixing the regression. > > Regression introduced by: > commit ec82cb793c9224e0692eed904f43490cf70e8258 > Author: Gustavo Padovan <gustavo.padovan@collabora.co.uk> > Date: Fri Oct 24 14:51:32 2014 +0100 > drm/i915: create a prepare phase for sprite plane updates > > Credits to Imre Deak for pointing out the exact lines that were wrong. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85634 > Testcase: igt/pm_rpm/legacy-planes > Testcase: igt/pm_rpm/legacy-planes-dpms > Testcase: igt/pm_rpm/universal-planes > Testcase: igt/pm_rpm/universal-planes-dpms > Credits-to: Imre Deak <imre.deak@intel.com> > Cc: Gustavo Padovan <gustavo.padovan@collabora.co.uk> > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> > Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> > --- > drivers/gpu/drm/i915/intel_sprite.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c > index 8b80d68..1c874309 100644 > --- a/drivers/gpu/drm/i915/intel_sprite.c > +++ b/drivers/gpu/drm/i915/intel_sprite.c > @@ -1197,10 +1197,11 @@ intel_prepare_sprite_plane(struct drm_plane *plane, > struct drm_device *dev = plane->dev; > struct drm_crtc *crtc = state->crtc; > struct intel_crtc *intel_crtc = to_intel_crtc(crtc); > + struct intel_plane *intel_plane = to_intel_plane(plane); > enum pipe pipe = intel_crtc->pipe; > struct drm_framebuffer *fb = state->fb; > struct drm_i915_gem_object *obj = intel_fb_obj(fb); > - struct drm_i915_gem_object *old_obj = intel_fb_obj(plane->fb); > + struct drm_i915_gem_object *old_obj = intel_plane->obj; You need to change intel_commit_sprite_plane() too. Othwerwise something like this could happen: 1. .update_plane(fb=A) // note plane->fb=NULL here -> prepare() -> pin(A) -> obj=A -> commit() -> nop ... plane->fb=A 2. .crtc_disable() -> disable() -> unpin(A) -> obj=NULL 3. .update_plane(fb=B) // note plane->fb=A here still -> prepare() -> pin(B) -> commit() -> unpin(A) -> obj=B ... plane->fb=B So we still get the double unpin of A. I take it our basic plane tests didn't catch this? > int ret; > > if (old_obj != obj) { > -- > 2.1.1 -- Ville Syrjälä Intel OTC _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] drm/i915: use the correct obj when preparing the sprite plane 2014-10-30 19:10 ` Ville Syrjälä @ 2014-10-30 19:33 ` Paulo Zanoni 2014-11-10 16:47 ` Paulo Zanoni 1 sibling, 0 replies; 24+ messages in thread From: Paulo Zanoni @ 2014-10-30 19:33 UTC (permalink / raw) To: Ville Syrjälä Cc: Intel Graphics Development, Gustavo Padovan, Paulo Zanoni 2014-10-30 17:10 GMT-02:00 Ville Syrjälä <ville.syrjala@linux.intel.com>: > On Thu, Oct 30, 2014 at 04:02:01PM -0200, Paulo Zanoni wrote: >> From: Paulo Zanoni <paulo.r.zanoni@intel.com> >> >> Commit "drm/i915: create a prepare phase for sprite plane updates" >> changed the old_obj pointer we use when committing sprite planes, >> which caused a WARN() and a BUG() to be triggered. This patch should >> revert the code back to the previous behavior, fixing the regression. >> >> Regression introduced by: >> commit ec82cb793c9224e0692eed904f43490cf70e8258 >> Author: Gustavo Padovan <gustavo.padovan@collabora.co.uk> >> Date: Fri Oct 24 14:51:32 2014 +0100 >> drm/i915: create a prepare phase for sprite plane updates >> >> Credits to Imre Deak for pointing out the exact lines that were wrong. >> >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85634 >> Testcase: igt/pm_rpm/legacy-planes >> Testcase: igt/pm_rpm/legacy-planes-dpms >> Testcase: igt/pm_rpm/universal-planes >> Testcase: igt/pm_rpm/universal-planes-dpms >> Credits-to: Imre Deak <imre.deak@intel.com> >> Cc: Gustavo Padovan <gustavo.padovan@collabora.co.uk> >> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> >> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> >> --- >> drivers/gpu/drm/i915/intel_sprite.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c >> index 8b80d68..1c874309 100644 >> --- a/drivers/gpu/drm/i915/intel_sprite.c >> +++ b/drivers/gpu/drm/i915/intel_sprite.c >> @@ -1197,10 +1197,11 @@ intel_prepare_sprite_plane(struct drm_plane *plane, >> struct drm_device *dev = plane->dev; >> struct drm_crtc *crtc = state->crtc; >> struct intel_crtc *intel_crtc = to_intel_crtc(crtc); >> + struct intel_plane *intel_plane = to_intel_plane(plane); >> enum pipe pipe = intel_crtc->pipe; >> struct drm_framebuffer *fb = state->fb; >> struct drm_i915_gem_object *obj = intel_fb_obj(fb); >> - struct drm_i915_gem_object *old_obj = intel_fb_obj(plane->fb); >> + struct drm_i915_gem_object *old_obj = intel_plane->obj; > > You need to change intel_commit_sprite_plane() too. Othwerwise something > like this could happen: > > 1. .update_plane(fb=A) > // note plane->fb=NULL here > -> prepare() -> pin(A) -> obj=A > -> commit() -> nop > ... > plane->fb=A > > 2. .crtc_disable() > -> disable() -> unpin(A) -> obj=NULL > > 3. .update_plane(fb=B) > // note plane->fb=A here still > -> prepare() -> pin(B) > -> commit() -> unpin(A) -> obj=B > ... > plane->fb=B > > So we still get the double unpin of A. > > I take it our basic plane tests didn't catch this? I didn't run any, nor associated any of the recent bug reports with that. Feel free to write tests if you can think of an easy way to exploit the bug. I also won't mind if someone else writes/sends v2 of this patch :) > >> int ret; >> >> if (old_obj != obj) { >> -- >> 2.1.1 > > -- > Ville Syrjälä > Intel OTC -- Paulo Zanoni _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH] drm/i915: use the correct obj when preparing the sprite plane 2014-10-30 19:10 ` Ville Syrjälä 2014-10-30 19:33 ` Paulo Zanoni @ 2014-11-10 16:47 ` Paulo Zanoni 2014-11-10 17:15 ` Ville Syrjälä 2014-11-11 8:41 ` [PATCH] drm/i915: use the correct obj when preparing shuang.he 1 sibling, 2 replies; 24+ messages in thread From: Paulo Zanoni @ 2014-11-10 16:47 UTC (permalink / raw) To: intel-gfx; +Cc: Gustavo Padovan, Paulo Zanoni From: Paulo Zanoni <paulo.r.zanoni@intel.com> Commit "drm/i915: create a prepare phase for sprite plane updates" changed the old_obj pointer we use when committing sprite planes, which caused a WARN() and a BUG() to be triggered. Later, commit "drm/i915: use intel_fb_obj() macros to assign gem objects" introduced the same problem to function intel_commit_sprite_plane(). Regression introduced by: commit ec82cb793c9224e0692eed904f43490cf70e8258 Author: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Date: Fri Oct 24 14:51:32 2014 +0100 drm/i915: create a prepare phase for sprite plane updates and: commit 77cde95217484e845743818691df026cec2534f4 Author: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Date: Fri Oct 24 14:51:33 2014 +0100 drm/i915: use intel_fb_obj() macros to assign gem objects Credits to Imre Deak for pointing out the exact lines that were wrong. v2: Also fix intel_commit_sprite_plane() (Ville) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85634 Testcase: igt/pm_rpm/legacy-planes Testcase: igt/pm_rpm/legacy-planes-dpms Testcase: igt/pm_rpm/universal-planes Testcase: igt/pm_rpm/universal-planes-dpms Credits-to: Imre Deak <imre.deak@intel.com> Cc: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> --- drivers/gpu/drm/i915/intel_sprite.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c index 64076555..7d9c340 100644 --- a/drivers/gpu/drm/i915/intel_sprite.c +++ b/drivers/gpu/drm/i915/intel_sprite.c @@ -1264,10 +1264,11 @@ intel_prepare_sprite_plane(struct drm_plane *plane, struct drm_device *dev = plane->dev; struct drm_crtc *crtc = state->crtc; struct intel_crtc *intel_crtc = to_intel_crtc(crtc); + struct intel_plane *intel_plane = to_intel_plane(plane); enum pipe pipe = intel_crtc->pipe; struct drm_framebuffer *fb = state->fb; struct drm_i915_gem_object *obj = intel_fb_obj(fb); - struct drm_i915_gem_object *old_obj = intel_fb_obj(plane->fb); + struct drm_i915_gem_object *old_obj = intel_plane->obj; int ret; if (old_obj != obj) { @@ -1302,7 +1303,7 @@ intel_commit_sprite_plane(struct drm_plane *plane, enum pipe pipe = intel_crtc->pipe; struct drm_framebuffer *fb = state->fb; struct drm_i915_gem_object *obj = intel_fb_obj(fb); - struct drm_i915_gem_object *old_obj = intel_fb_obj(plane->fb); + struct drm_i915_gem_object *old_obj = intel_plane->obj; int crtc_x, crtc_y; unsigned int crtc_w, crtc_h; uint32_t src_x, src_y, src_w, src_h; -- 2.1.1 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: [PATCH] drm/i915: use the correct obj when preparing the sprite plane 2014-11-10 16:47 ` Paulo Zanoni @ 2014-11-10 17:15 ` Ville Syrjälä 2014-11-11 9:30 ` How to handle planes/fbs when disabling the crtc? (was Re: [Intel-gfx] [PATCH] drm/i915: use the correct obj when preparing the sprite plane) Daniel Vetter 2014-11-11 9:31 ` [PATCH] drm/i915: use the correct obj when preparing the sprite plane Daniel Vetter 2014-11-11 8:41 ` [PATCH] drm/i915: use the correct obj when preparing shuang.he 1 sibling, 2 replies; 24+ messages in thread From: Ville Syrjälä @ 2014-11-10 17:15 UTC (permalink / raw) To: Paulo Zanoni; +Cc: intel-gfx, Gustavo Padovan, Paulo Zanoni On Mon, Nov 10, 2014 at 02:47:30PM -0200, Paulo Zanoni wrote: > From: Paulo Zanoni <paulo.r.zanoni@intel.com> > > Commit "drm/i915: create a prepare phase for sprite plane updates" > changed the old_obj pointer we use when committing sprite planes, > which caused a WARN() and a BUG() to be triggered. Later, commit > "drm/i915: use intel_fb_obj() macros to assign gem objects" introduced > the same problem to function intel_commit_sprite_plane(). > > Regression introduced by: > commit ec82cb793c9224e0692eed904f43490cf70e8258 > Author: Gustavo Padovan <gustavo.padovan@collabora.co.uk> > Date: Fri Oct 24 14:51:32 2014 +0100 > drm/i915: create a prepare phase for sprite plane updates > and: > commit 77cde95217484e845743818691df026cec2534f4 > Author: Gustavo Padovan <gustavo.padovan@collabora.co.uk> > Date: Fri Oct 24 14:51:33 2014 +0100 > drm/i915: use intel_fb_obj() macros to assign gem objects > > Credits to Imre Deak for pointing out the exact lines that were wrong. > > v2: Also fix intel_commit_sprite_plane() (Ville) > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85634 > Testcase: igt/pm_rpm/legacy-planes > Testcase: igt/pm_rpm/legacy-planes-dpms > Testcase: igt/pm_rpm/universal-planes > Testcase: igt/pm_rpm/universal-planes-dpms > Credits-to: Imre Deak <imre.deak@intel.com> > Cc: Gustavo Padovan <gustavo.padovan@collabora.co.uk> > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> > Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Yep, I believe that should do it. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> As a side note if someone is looking for stuff to do, then the pin/unpin logic might be good thing to look at. We're currently a bit inconsistent whether we have the buffer pinned when the plane is disabled, or just otherwise invisible, or when the crtc itself is disabled. And I guess cooking up some tests to poke at planes with disabled crtcs might be in order too, as well as all kinds of variations on the crtc_enable->plane_enable->crtc_disable->plane_disable theme. > --- > drivers/gpu/drm/i915/intel_sprite.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c > index 64076555..7d9c340 100644 > --- a/drivers/gpu/drm/i915/intel_sprite.c > +++ b/drivers/gpu/drm/i915/intel_sprite.c > @@ -1264,10 +1264,11 @@ intel_prepare_sprite_plane(struct drm_plane *plane, > struct drm_device *dev = plane->dev; > struct drm_crtc *crtc = state->crtc; > struct intel_crtc *intel_crtc = to_intel_crtc(crtc); > + struct intel_plane *intel_plane = to_intel_plane(plane); > enum pipe pipe = intel_crtc->pipe; > struct drm_framebuffer *fb = state->fb; > struct drm_i915_gem_object *obj = intel_fb_obj(fb); > - struct drm_i915_gem_object *old_obj = intel_fb_obj(plane->fb); > + struct drm_i915_gem_object *old_obj = intel_plane->obj; > int ret; > > if (old_obj != obj) { > @@ -1302,7 +1303,7 @@ intel_commit_sprite_plane(struct drm_plane *plane, > enum pipe pipe = intel_crtc->pipe; > struct drm_framebuffer *fb = state->fb; > struct drm_i915_gem_object *obj = intel_fb_obj(fb); > - struct drm_i915_gem_object *old_obj = intel_fb_obj(plane->fb); > + struct drm_i915_gem_object *old_obj = intel_plane->obj; > int crtc_x, crtc_y; > unsigned int crtc_w, crtc_h; > uint32_t src_x, src_y, src_w, src_h; > -- > 2.1.1 -- Ville Syrjälä Intel OTC _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 24+ messages in thread
* How to handle planes/fbs when disabling the crtc? (was Re: [Intel-gfx] [PATCH] drm/i915: use the correct obj when preparing the sprite plane) 2014-11-10 17:15 ` Ville Syrjälä @ 2014-11-11 9:30 ` Daniel Vetter 2014-11-12 11:49 ` Ville Syrjälä 2014-11-11 9:31 ` [PATCH] drm/i915: use the correct obj when preparing the sprite plane Daniel Vetter 1 sibling, 1 reply; 24+ messages in thread From: Daniel Vetter @ 2014-11-11 9:30 UTC (permalink / raw) To: Ville Syrjälä Cc: Gustavo Padovan, intel-gfx, DRI Development, Paulo Zanoni On Mon, Nov 10, 2014 at 07:15:04PM +0200, Ville Syrjälä wrote: > As a side note if someone is looking for stuff to do, then the pin/unpin > logic might be good thing to look at. We're currently a bit inconsistent > whether we have the buffer pinned when the plane is disabled, or just > otherwise invisible, or when the crtc itself is disabled. And I guess > cooking up some tests to poke at planes with disabled crtcs might be in > order too, as well as all kinds of variations on the > crtc_enable->plane_enable->crtc_disable->plane_disable theme. Hm, I've thought that thus far we've kept the buffer pinned when the crtc is enabled (irrespective or crtc state). And when the crtc gets disabled we dropped the buffers. Then planes happened and everything got messy. Actually I'm not really sure what the right semantics are here - in the atomic helpers I don't disable planes/framebuffers. Which is consistent with the legacy plane interface, but not consistent with the legacy setCrtc ioctl. Anyone has a good idea how to handle all this properly? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: How to handle planes/fbs when disabling the crtc? (was Re: [Intel-gfx] [PATCH] drm/i915: use the correct obj when preparing the sprite plane) 2014-11-11 9:30 ` How to handle planes/fbs when disabling the crtc? (was Re: [Intel-gfx] [PATCH] drm/i915: use the correct obj when preparing the sprite plane) Daniel Vetter @ 2014-11-12 11:49 ` Ville Syrjälä 2014-11-12 14:22 ` How to handle planes/fbs when disabling the crtc? (was " Daniel Vetter 0 siblings, 1 reply; 24+ messages in thread From: Ville Syrjälä @ 2014-11-12 11:49 UTC (permalink / raw) To: Daniel Vetter; +Cc: Gustavo Padovan, intel-gfx, DRI Development, Paulo Zanoni On Tue, Nov 11, 2014 at 10:30:57AM +0100, Daniel Vetter wrote: > On Mon, Nov 10, 2014 at 07:15:04PM +0200, Ville Syrjälä wrote: > > As a side note if someone is looking for stuff to do, then the pin/unpin > > logic might be good thing to look at. We're currently a bit inconsistent > > whether we have the buffer pinned when the plane is disabled, or just > > otherwise invisible, or when the crtc itself is disabled. And I guess > > cooking up some tests to poke at planes with disabled crtcs might be in > > order too, as well as all kinds of variations on the > > crtc_enable->plane_enable->crtc_disable->plane_disable theme. > > Hm, I've thought that thus far we've kept the buffer pinned when the crtc > is enabled (irrespective or crtc state). And when the crtc gets disabled > we dropped the buffers. Then planes happened and everything got messy. > > Actually I'm not really sure what the right semantics are here - in the > atomic helpers I don't disable planes/framebuffers. Which is consistent > with the legacy plane interface, but not consistent with the legacy > setCrtc ioctl. > > Anyone has a good idea how to handle all this properly? Well I think we should avoid the "change in property X changes property Y" problem. That means leaving the plane->fb alone when the crtc is disabled. But as as far as the pinning goes, my original idea was that we keep things pinned as long as plane->fb is set, whether the plane is invisible or crtc disabled. The idea was you could set up all the planes in advance, and then enable the crtc and it would at least not fail due to failure to pin the buffers. But that is rather wasteful and might prevent defragmenting the address space. So I suppose we should just change things so that at least we don't keep the buffers pinned when the crtc is disabled. And perhaps we should just go all the way and not pin when the plane is invisible, for any reason. -- Ville Syrjälä Intel OTC _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: How to handle planes/fbs when disabling the crtc? (was Re: [PATCH] drm/i915: use the correct obj when preparing the sprite plane) 2014-11-12 11:49 ` Ville Syrjälä @ 2014-11-12 14:22 ` Daniel Vetter 2014-11-12 14:45 ` Ville Syrjälä 0 siblings, 1 reply; 24+ messages in thread From: Daniel Vetter @ 2014-11-12 14:22 UTC (permalink / raw) To: Ville Syrjälä Cc: Paulo Zanoni, intel-gfx, DRI Development, Gustavo Padovan On Wed, Nov 12, 2014 at 01:49:47PM +0200, Ville Syrjälä wrote: > On Tue, Nov 11, 2014 at 10:30:57AM +0100, Daniel Vetter wrote: > > On Mon, Nov 10, 2014 at 07:15:04PM +0200, Ville Syrjälä wrote: > > > As a side note if someone is looking for stuff to do, then the pin/unpin > > > logic might be good thing to look at. We're currently a bit inconsistent > > > whether we have the buffer pinned when the plane is disabled, or just > > > otherwise invisible, or when the crtc itself is disabled. And I guess > > > cooking up some tests to poke at planes with disabled crtcs might be in > > > order too, as well as all kinds of variations on the > > > crtc_enable->plane_enable->crtc_disable->plane_disable theme. > > > > Hm, I've thought that thus far we've kept the buffer pinned when the crtc > > is enabled (irrespective or crtc state). And when the crtc gets disabled > > we dropped the buffers. Then planes happened and everything got messy. > > > > Actually I'm not really sure what the right semantics are here - in the > > atomic helpers I don't disable planes/framebuffers. Which is consistent > > with the legacy plane interface, but not consistent with the legacy > > setCrtc ioctl. > > > > Anyone has a good idea how to handle all this properly? > > Well I think we should avoid the "change in property X changes > property Y" problem. That means leaving the plane->fb alone when the > crtc is disabled. > > But as as far as the pinning goes, my original idea was that we keep > things pinned as long as plane->fb is set, whether the plane is > invisible or crtc disabled. The idea was you could set up all the planes > in advance, and then enable the crtc and it would at least not fail due > to failure to pin the buffers. > > But that is rather wasteful and might prevent defragmenting the address > space. So I suppose we should just change things so that at least we > don't keep the buffers pinned when the crtc is disabled. And perhaps > we should just go all the way and not pin when the plane is invisible, > for any reason. The problem is a bit that the legacy setCrtc does free the buffer, and userspace might rely on that. So if we decide to keep the plane fb around when the crtc is disabled we need to at least update the set_config atomic helper function to release the fb of the primary plane and unlink/disable the primary plane. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: How to handle planes/fbs when disabling the crtc? (was Re: [PATCH] drm/i915: use the correct obj when preparing the sprite plane) 2014-11-12 14:22 ` How to handle planes/fbs when disabling the crtc? (was " Daniel Vetter @ 2014-11-12 14:45 ` Ville Syrjälä 0 siblings, 0 replies; 24+ messages in thread From: Ville Syrjälä @ 2014-11-12 14:45 UTC (permalink / raw) To: Daniel Vetter; +Cc: Gustavo Padovan, intel-gfx, DRI Development, Paulo Zanoni On Wed, Nov 12, 2014 at 03:22:07PM +0100, Daniel Vetter wrote: > On Wed, Nov 12, 2014 at 01:49:47PM +0200, Ville Syrjälä wrote: > > On Tue, Nov 11, 2014 at 10:30:57AM +0100, Daniel Vetter wrote: > > > On Mon, Nov 10, 2014 at 07:15:04PM +0200, Ville Syrjälä wrote: > > > > As a side note if someone is looking for stuff to do, then the pin/unpin > > > > logic might be good thing to look at. We're currently a bit inconsistent > > > > whether we have the buffer pinned when the plane is disabled, or just > > > > otherwise invisible, or when the crtc itself is disabled. And I guess > > > > cooking up some tests to poke at planes with disabled crtcs might be in > > > > order too, as well as all kinds of variations on the > > > > crtc_enable->plane_enable->crtc_disable->plane_disable theme. > > > > > > Hm, I've thought that thus far we've kept the buffer pinned when the crtc > > > is enabled (irrespective or crtc state). And when the crtc gets disabled > > > we dropped the buffers. Then planes happened and everything got messy. > > > > > > Actually I'm not really sure what the right semantics are here - in the > > > atomic helpers I don't disable planes/framebuffers. Which is consistent > > > with the legacy plane interface, but not consistent with the legacy > > > setCrtc ioctl. > > > > > > Anyone has a good idea how to handle all this properly? > > > > Well I think we should avoid the "change in property X changes > > property Y" problem. That means leaving the plane->fb alone when the > > crtc is disabled. > > > > But as as far as the pinning goes, my original idea was that we keep > > things pinned as long as plane->fb is set, whether the plane is > > invisible or crtc disabled. The idea was you could set up all the planes > > in advance, and then enable the crtc and it would at least not fail due > > to failure to pin the buffers. > > > > But that is rather wasteful and might prevent defragmenting the address > > space. So I suppose we should just change things so that at least we > > don't keep the buffers pinned when the crtc is disabled. And perhaps > > we should just go all the way and not pin when the plane is invisible, > > for any reason. > > The problem is a bit that the legacy setCrtc does free the buffer, and > userspace might rely on that. So if we decide to keep the plane fb around > when the crtc is disabled we need to at least update the set_config atomic > helper function to release the fb of the primary plane and unlink/disable > the primary plane. Sounds reasonable. At least I'd prefer if we can keep such uglies neatly tucked away in their own legacy corner, and not let them spread into the general population. -- Ville Syrjälä Intel OTC _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] drm/i915: use the correct obj when preparing the sprite plane 2014-11-10 17:15 ` Ville Syrjälä 2014-11-11 9:30 ` How to handle planes/fbs when disabling the crtc? (was Re: [Intel-gfx] [PATCH] drm/i915: use the correct obj when preparing the sprite plane) Daniel Vetter @ 2014-11-11 9:31 ` Daniel Vetter 1 sibling, 0 replies; 24+ messages in thread From: Daniel Vetter @ 2014-11-11 9:31 UTC (permalink / raw) To: Ville Syrjälä; +Cc: Gustavo Padovan, intel-gfx, Paulo Zanoni On Mon, Nov 10, 2014 at 07:15:04PM +0200, Ville Syrjälä wrote: > On Mon, Nov 10, 2014 at 02:47:30PM -0200, Paulo Zanoni wrote: > > From: Paulo Zanoni <paulo.r.zanoni@intel.com> > > > > Commit "drm/i915: create a prepare phase for sprite plane updates" > > changed the old_obj pointer we use when committing sprite planes, > > which caused a WARN() and a BUG() to be triggered. Later, commit > > "drm/i915: use intel_fb_obj() macros to assign gem objects" introduced > > the same problem to function intel_commit_sprite_plane(). > > > > Regression introduced by: > > commit ec82cb793c9224e0692eed904f43490cf70e8258 > > Author: Gustavo Padovan <gustavo.padovan@collabora.co.uk> > > Date: Fri Oct 24 14:51:32 2014 +0100 > > drm/i915: create a prepare phase for sprite plane updates > > and: > > commit 77cde95217484e845743818691df026cec2534f4 > > Author: Gustavo Padovan <gustavo.padovan@collabora.co.uk> > > Date: Fri Oct 24 14:51:33 2014 +0100 > > drm/i915: use intel_fb_obj() macros to assign gem objects > > > > Credits to Imre Deak for pointing out the exact lines that were wrong. > > > > v2: Also fix intel_commit_sprite_plane() (Ville) > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85634 > > Testcase: igt/pm_rpm/legacy-planes > > Testcase: igt/pm_rpm/legacy-planes-dpms > > Testcase: igt/pm_rpm/universal-planes > > Testcase: igt/pm_rpm/universal-planes-dpms > > Credits-to: Imre Deak <imre.deak@intel.com> > > Cc: Gustavo Padovan <gustavo.padovan@collabora.co.uk> > > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> > > Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> > > Yep, I believe that should do it. > > Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Queued for -next, thanks for the patch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] drm/i915: use the correct obj when preparing 2014-11-10 16:47 ` Paulo Zanoni 2014-11-10 17:15 ` Ville Syrjälä @ 2014-11-11 8:41 ` shuang.he 1 sibling, 0 replies; 24+ messages in thread From: shuang.he @ 2014-11-11 8:41 UTC (permalink / raw) To: shuang.he, intel-gfx, przanoni Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang.he@intel.com) -------------------------------------Summary------------------------------------- Platform: baseline_drm_intel_nightly_pass_rate->patch_applied_pass_rate BYT: pass/total=277/348->277/348 PNV: pass/total=323/328->325/328 ILK: pass/total=328/330->330/330 IVB: pass/total=545/546->544/546 SNB: pass/total=558/563->562/563 HSW: pass/total=587/591->590/591 BDW: pass/total=435/435->434/435 -------------------------------------Detailed------------------------------------- test_platform: test_suite, test_case, result_with_drm_intel_nightly(count, machine_id...)...->result_with_patch_applied(count, machine_id)... PNV: Intel_gpu_tools, igt_gem_mmap_offset_exhaustion, DMESG_WARN(2, M23M24)PASS(14, M24M23M7) -> PASS(4, M7) PNV: Intel_gpu_tools, igt_gem_unref_active_buffers, DMESG_WARN(2, M23)PASS(14, M24M23M7) -> PASS(4, M7) ILK: Intel_gpu_tools, igt_kms_render_gpu-blit, DMESG_WARN(1, M26)PASS(15, M6M26M37) -> PASS(4, M6) ILK: Intel_gpu_tools, igt_kms_flip_wf_vblank-vs-dpms-interruptible, DMESG_WARN(1, M26)PASS(15, M6M26M37) -> PASS(4, M6) IVB: Intel_gpu_tools, igt_gem_bad_reloc_negative-reloc, NSPT(5, M4M34)PASS(11, M34M4) -> NSPT(2, M4)PASS(2, M4) IVB: Intel_gpu_tools, igt_kms_plane_plane-position-covered-pipe-A-plane-1, TIMEOUT(1, M34)PASS(9, M4) -> PASS(4, M4) IVB: Intel_gpu_tools, igt_kms_flip_absolute-wf_vblank-interruptible, PASS(4, M34M4) -> DMESG_WARN(1, M4)PASS(3, M4) SNB: Intel_gpu_tools, igt_kms_cursor_crc_cursor-256x256-sliding, DMESG_WARN(3, M35M22)PASS(7, M22M35) -> PASS(4, M35) SNB: Intel_gpu_tools, igt_kms_plane_plane-panning-top-left-pipe-A-plane-1, PASS(1, M35) -> FAIL(1, M35)PASS(3, M35) SNB: Intel_gpu_tools, igt_pm_rpm_legacy-planes, TIMEOUT(1, M35) -> TIMEOUT(3, M35)PASS(1, M35) SNB: Intel_gpu_tools, igt_pm_rpm_legacy-planes-dpms, TIMEOUT(1, M35) -> TIMEOUT(3, M35)PASS(1, M35) SNB: Intel_gpu_tools, igt_pm_rpm_universal-planes, TIMEOUT(1, M35) -> TIMEOUT(2, M35)PASS(1, M35) SNB: Intel_gpu_tools, igt_pm_rpm_universal-planes-dpms, TIMEOUT(1, M35) -> PASS(1, M35) HSW: Intel_gpu_tools, igt_gem_bad_reloc_negative-reloc, NSPT(4, M39M20M40)PASS(9, M40M39M20) -> NSPT(2, M19)PASS(2, M19) HSW: Intel_gpu_tools, igt_pm_rpm_legacy-planes, TIMEOUT(1, M40) -> TIMEOUT(3, M19)PASS(1, M19) HSW: Intel_gpu_tools, igt_pm_rpm_legacy-planes-dpms, TIMEOUT(1, M40) -> TIMEOUT(3, M19)PASS(1, M19) HSW: Intel_gpu_tools, igt_pm_rpm_universal-planes, TIMEOUT(1, M40) -> TIMEOUT(2, M19)PASS(1, M19) HSW: Intel_gpu_tools, igt_pm_rpm_universal-planes-dpms, TIMEOUT(1, M40) -> PASS(1, M19) BDW: Intel_gpu_tools, igt_gem_reset_stats_ban-bsd, PASS(16, M30M28M42) -> DMESG_WARN(1, M30)PASS(3, M30) _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH v4 3/5] drm/i915: use intel_fb_obj() macros to assign gem objects 2014-10-24 13:51 [PATCH v4 1/5] drm/i915: create a prepare step for primary planes updates Gustavo Padovan 2014-10-24 13:51 ` [PATCH v4 2/5] drm/i915: create a prepare phase for sprite plane updates Gustavo Padovan @ 2014-10-24 13:51 ` Gustavo Padovan 2014-10-24 13:51 ` [PATCH v4 4/5] drm/i915: only flip frontbuffer if crtc is active Gustavo Padovan 2014-10-24 13:51 ` [PATCH v4 5/5] drm/i915: remove intel_crtc_cursor_set_obj() Gustavo Padovan 3 siblings, 0 replies; 24+ messages in thread From: Gustavo Padovan @ 2014-10-24 13:51 UTC (permalink / raw) To: intel-gfx; +Cc: Gustavo Padovan, dri-devel From: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Use the macros makes the code cleaner and it also checks for a NULL fb. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> --- drivers/gpu/drm/i915/intel_sprite.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c index 3631b0e..8b80d68 100644 --- a/drivers/gpu/drm/i915/intel_sprite.c +++ b/drivers/gpu/drm/i915/intel_sprite.c @@ -1032,8 +1032,7 @@ intel_check_sprite_plane(struct drm_plane *plane, struct intel_crtc *intel_crtc = to_intel_crtc(state->crtc); struct intel_plane *intel_plane = to_intel_plane(plane); struct drm_framebuffer *fb = state->fb; - struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb); - struct drm_i915_gem_object *obj = intel_fb->obj; + struct drm_i915_gem_object *obj = intel_fb_obj(fb); int crtc_x, crtc_y; unsigned int crtc_w, crtc_h; uint32_t src_x, src_y, src_w, src_h; @@ -1235,9 +1234,8 @@ intel_commit_sprite_plane(struct drm_plane *plane, struct intel_plane *intel_plane = to_intel_plane(plane); enum pipe pipe = intel_crtc->pipe; struct drm_framebuffer *fb = state->fb; - struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb); - struct drm_i915_gem_object *obj = intel_fb->obj; - struct drm_i915_gem_object *old_obj = intel_plane->obj; + struct drm_i915_gem_object *obj = intel_fb_obj(fb); + struct drm_i915_gem_object *old_obj = intel_fb_obj(plane->fb); int crtc_x, crtc_y; unsigned int crtc_w, crtc_h; uint32_t src_x, src_y, src_w, src_h; -- 1.9.3 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply related [flat|nested] 24+ messages in thread
* [PATCH v4 4/5] drm/i915: only flip frontbuffer if crtc is active 2014-10-24 13:51 [PATCH v4 1/5] drm/i915: create a prepare step for primary planes updates Gustavo Padovan 2014-10-24 13:51 ` [PATCH v4 2/5] drm/i915: create a prepare phase for sprite plane updates Gustavo Padovan 2014-10-24 13:51 ` [PATCH v4 3/5] drm/i915: use intel_fb_obj() macros to assign gem objects Gustavo Padovan @ 2014-10-24 13:51 ` Gustavo Padovan 2014-10-24 15:07 ` Ville Syrjälä 2014-10-24 13:51 ` [PATCH v4 5/5] drm/i915: remove intel_crtc_cursor_set_obj() Gustavo Padovan 3 siblings, 1 reply; 24+ messages in thread From: Gustavo Padovan @ 2014-10-24 13:51 UTC (permalink / raw) To: intel-gfx; +Cc: Gustavo Padovan, dri-devel From: Gustavo Padovan <gustavo.padovan@collabora.co.uk> There is no point in flipping a buffer for a disabled crtc. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> --- drivers/gpu/drm/i915/intel_display.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 8530401..9a913f5 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -8544,9 +8544,9 @@ static int intel_crtc_cursor_set_obj(struct drm_crtc *crtc, if (old_width != width) intel_update_watermarks(crtc); intel_crtc_update_cursor(crtc, intel_crtc->cursor_bo != NULL); - } - intel_frontbuffer_flip(dev, INTEL_FRONTBUFFER_CURSOR(pipe)); + intel_frontbuffer_flip(dev, INTEL_FRONTBUFFER_CURSOR(pipe)); + } return 0; fail_unpin: -- 1.9.3 ^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: [PATCH v4 4/5] drm/i915: only flip frontbuffer if crtc is active 2014-10-24 13:51 ` [PATCH v4 4/5] drm/i915: only flip frontbuffer if crtc is active Gustavo Padovan @ 2014-10-24 15:07 ` Ville Syrjälä 2014-10-27 9:10 ` Daniel Vetter 0 siblings, 1 reply; 24+ messages in thread From: Ville Syrjälä @ 2014-10-24 15:07 UTC (permalink / raw) To: Gustavo Padovan; +Cc: intel-gfx, Gustavo Padovan, dri-devel On Fri, Oct 24, 2014 at 02:51:34PM +0100, Gustavo Padovan wrote: > From: Gustavo Padovan <gustavo.padovan@collabora.co.uk> > > There is no point in flipping a buffer for a disabled crtc. That thing doesn't actually flip but just signal the frontbuffer tracking code that either has just flipped or is going to real soon now (tm). But yeah, still makes no sense when the entire pipe is off, so: Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> > > Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> > --- > drivers/gpu/drm/i915/intel_display.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c > index 8530401..9a913f5 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -8544,9 +8544,9 @@ static int intel_crtc_cursor_set_obj(struct drm_crtc *crtc, > if (old_width != width) > intel_update_watermarks(crtc); > intel_crtc_update_cursor(crtc, intel_crtc->cursor_bo != NULL); > - } > > - intel_frontbuffer_flip(dev, INTEL_FRONTBUFFER_CURSOR(pipe)); > + intel_frontbuffer_flip(dev, INTEL_FRONTBUFFER_CURSOR(pipe)); > + } > > return 0; > fail_unpin: > -- > 1.9.3 > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- Ville Syrjälä Intel OTC ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v4 4/5] drm/i915: only flip frontbuffer if crtc is active 2014-10-24 15:07 ` Ville Syrjälä @ 2014-10-27 9:10 ` Daniel Vetter 0 siblings, 0 replies; 24+ messages in thread From: Daniel Vetter @ 2014-10-27 9:10 UTC (permalink / raw) To: Ville Syrjälä; +Cc: intel-gfx, Gustavo Padovan, dri-devel On Fri, Oct 24, 2014 at 06:07:15PM +0300, Ville Syrjälä wrote: > On Fri, Oct 24, 2014 at 02:51:34PM +0100, Gustavo Padovan wrote: > > From: Gustavo Padovan <gustavo.padovan@collabora.co.uk> > > > > There is no point in flipping a buffer for a disabled crtc. > > That thing doesn't actually flip but just signal the frontbuffer > tracking code that either has just flipped or is going to real soon now > (tm). But yeah, still makes no sense when the entire pipe is off, so: > > Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Queued for -next, thanks for the patch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH v4 5/5] drm/i915: remove intel_crtc_cursor_set_obj() 2014-10-24 13:51 [PATCH v4 1/5] drm/i915: create a prepare step for primary planes updates Gustavo Padovan ` (2 preceding siblings ...) 2014-10-24 13:51 ` [PATCH v4 4/5] drm/i915: only flip frontbuffer if crtc is active Gustavo Padovan @ 2014-10-24 13:51 ` Gustavo Padovan 2014-10-24 15:16 ` Ville Syrjälä 2014-10-28 12:35 ` [Intel-gfx] " Ville Syrjälä 3 siblings, 2 replies; 24+ messages in thread From: Gustavo Padovan @ 2014-10-24 13:51 UTC (permalink / raw) To: intel-gfx; +Cc: Gustavo Padovan, dri-devel From: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Merge it into the plane update_plane() callback and make other users use the update_plane() functions instead. The fb != crtc->cursor->fb was already inside intel_crtc_cursor_set_obj() so we fold intel_crtc_cursor_set_obj() inside intel_commit_cursor_plane() and merge both paths into one. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> --- drivers/gpu/drm/i915/intel_display.c | 215 ++++++++++++++++------------------- 1 file changed, 100 insertions(+), 115 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 9a913f5..60ec165 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -8453,109 +8453,6 @@ static bool cursor_size_ok(struct drm_device *dev, return true; } -static int intel_crtc_cursor_set_obj(struct drm_crtc *crtc, - struct drm_i915_gem_object *obj, - uint32_t width, uint32_t height) -{ - struct drm_device *dev = crtc->dev; - struct drm_i915_private *dev_priv = dev->dev_private; - struct intel_crtc *intel_crtc = to_intel_crtc(crtc); - enum pipe pipe = intel_crtc->pipe; - unsigned old_width; - uint32_t addr; - int ret; - - /* if we want to turn off the cursor ignore width and height */ - if (!obj) { - DRM_DEBUG_KMS("cursor off\n"); - addr = 0; - mutex_lock(&dev->struct_mutex); - goto finish; - } - - /* we only need to pin inside GTT if cursor is non-phy */ - mutex_lock(&dev->struct_mutex); - if (!INTEL_INFO(dev)->cursor_needs_physical) { - unsigned alignment; - - /* - * Global gtt pte registers are special registers which actually - * forward writes to a chunk of system memory. Which means that - * there is no risk that the register values disappear as soon - * as we call intel_runtime_pm_put(), so it is correct to wrap - * only the pin/unpin/fence and not more. - */ - intel_runtime_pm_get(dev_priv); - - /* Note that the w/a also requires 2 PTE of padding following - * the bo. We currently fill all unused PTE with the shadow - * page and so we should always have valid PTE following the - * cursor preventing the VT-d warning. - */ - alignment = 0; - if (need_vtd_wa(dev)) - alignment = 64*1024; - - ret = i915_gem_object_pin_to_display_plane(obj, alignment, NULL); - if (ret) { - DRM_DEBUG_KMS("failed to move cursor bo into the GTT\n"); - intel_runtime_pm_put(dev_priv); - goto fail_locked; - } - - ret = i915_gem_object_put_fence(obj); - if (ret) { - DRM_DEBUG_KMS("failed to release fence for cursor"); - intel_runtime_pm_put(dev_priv); - goto fail_unpin; - } - - addr = i915_gem_obj_ggtt_offset(obj); - - intel_runtime_pm_put(dev_priv); - } else { - int align = IS_I830(dev) ? 16 * 1024 : 256; - ret = i915_gem_object_attach_phys(obj, align); - if (ret) { - DRM_DEBUG_KMS("failed to attach phys object\n"); - goto fail_locked; - } - addr = obj->phys_handle->busaddr; - } - - finish: - if (intel_crtc->cursor_bo) { - if (!INTEL_INFO(dev)->cursor_needs_physical) - i915_gem_object_unpin_from_display_plane(intel_crtc->cursor_bo); - } - - i915_gem_track_fb(intel_crtc->cursor_bo, obj, - INTEL_FRONTBUFFER_CURSOR(pipe)); - mutex_unlock(&dev->struct_mutex); - - old_width = intel_crtc->cursor_width; - - intel_crtc->cursor_addr = addr; - intel_crtc->cursor_bo = obj; - intel_crtc->cursor_width = width; - intel_crtc->cursor_height = height; - - if (intel_crtc->active) { - if (old_width != width) - intel_update_watermarks(crtc); - intel_crtc_update_cursor(crtc, intel_crtc->cursor_bo != NULL); - - intel_frontbuffer_flip(dev, INTEL_FRONTBUFFER_CURSOR(pipe)); - } - - return 0; -fail_unpin: - i915_gem_object_unpin_from_display_plane(obj); -fail_locked: - mutex_unlock(&dev->struct_mutex); - return ret; -} - static void intel_crtc_gamma_set(struct drm_crtc *crtc, u16 *red, u16 *green, u16 *blue, uint32_t start, uint32_t size) { @@ -11906,7 +11803,8 @@ intel_cursor_plane_disable(struct drm_plane *plane) BUG_ON(!plane->crtc); - return intel_crtc_cursor_set_obj(plane->crtc, NULL, 0, 0); + return plane->funcs->update_plane(plane, plane->crtc, NULL, + 0, 0, 0, 0, 0, 0, 0, 0); } static int @@ -11970,26 +11868,113 @@ intel_commit_cursor_plane(struct drm_plane *plane, struct intel_plane_state *state) { struct drm_crtc *crtc = state->crtc; + struct drm_device *dev = crtc->dev; + struct drm_i915_private *dev_priv = dev->dev_private; struct drm_framebuffer *fb = state->fb; struct intel_crtc *intel_crtc = to_intel_crtc(crtc); - struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb); - struct drm_i915_gem_object *obj = intel_fb->obj; - int crtc_w, crtc_h; + struct drm_i915_gem_object *obj = intel_fb_obj(fb); + enum pipe pipe = intel_crtc->pipe; + unsigned old_width; + uint32_t addr; + int ret; crtc->cursor_x = state->orig_dst.x1; crtc->cursor_y = state->orig_dst.y1; - if (fb != crtc->cursor->fb) { - crtc_w = drm_rect_width(&state->orig_dst); - crtc_h = drm_rect_height(&state->orig_dst); - return intel_crtc_cursor_set_obj(crtc, obj, crtc_w, crtc_h); + + if (intel_crtc->cursor_bo == obj) + goto update; + + /* if we want to turn off the cursor ignore width and height */ + if (!obj) { + DRM_DEBUG_KMS("cursor off\n"); + addr = 0; + mutex_lock(&dev->struct_mutex); + goto finish; + } + + /* we only need to pin inside GTT if cursor is non-phy */ + mutex_lock(&dev->struct_mutex); + if (!INTEL_INFO(dev)->cursor_needs_physical) { + unsigned alignment; + + /* + * Global gtt pte registers are special registers which actually + * forward writes to a chunk of system memory. Which means that + * there is no risk that the register values disappear as soon + * as we call intel_runtime_pm_put(), so it is correct to wrap + * only the pin/unpin/fence and not more. + */ + intel_runtime_pm_get(dev_priv); + + /* Note that the w/a also requires 2 PTE of padding following + * the bo. We currently fill all unused PTE with the shadow + * page and so we should always have valid PTE following the + * cursor preventing the VT-d warning. + */ + alignment = 0; + if (need_vtd_wa(dev)) + alignment = 64*1024; + + ret = i915_gem_object_pin_to_display_plane(obj, alignment, NULL); + if (ret) { + DRM_DEBUG_KMS("failed to move cursor bo into the GTT\n"); + intel_runtime_pm_put(dev_priv); + goto fail_locked; + } + + ret = i915_gem_object_put_fence(obj); + if (ret) { + DRM_DEBUG_KMS("failed to release fence for cursor"); + intel_runtime_pm_put(dev_priv); + goto fail_unpin; + } + + addr = i915_gem_obj_ggtt_offset(obj); + + intel_runtime_pm_put(dev_priv); } else { - intel_crtc_update_cursor(crtc, state->visible); + int align = IS_I830(dev) ? 16 * 1024 : 256; + ret = i915_gem_object_attach_phys(obj, align); + if (ret) { + DRM_DEBUG_KMS("failed to attach phys object\n"); + goto fail_locked; + } + addr = obj->phys_handle->busaddr; + } - intel_frontbuffer_flip(crtc->dev, - INTEL_FRONTBUFFER_CURSOR(intel_crtc->pipe)); +finish: + if (intel_crtc->cursor_bo) { + if (!INTEL_INFO(dev)->cursor_needs_physical) + i915_gem_object_unpin_from_display_plane(intel_crtc->cursor_bo); + } - return 0; + i915_gem_track_fb(intel_crtc->cursor_bo, obj, + INTEL_FRONTBUFFER_CURSOR(pipe)); + mutex_unlock(&dev->struct_mutex); + + intel_crtc->cursor_addr = addr; + intel_crtc->cursor_bo = obj; +update: + old_width = intel_crtc->cursor_width; + + intel_crtc->cursor_width = drm_rect_width(&state->orig_dst); + intel_crtc->cursor_height = drm_rect_height(&state->orig_dst); + + if (intel_crtc->active) { + if (old_width != intel_crtc->cursor_width) + intel_update_watermarks(crtc); + intel_crtc_update_cursor(crtc, state->visible); + + intel_frontbuffer_flip(dev, INTEL_FRONTBUFFER_CURSOR(pipe)); } + + return 0; +fail_unpin: + i915_gem_object_unpin_from_display_plane(obj); +fail_locked: + mutex_unlock(&dev->struct_mutex); + drm_gem_object_unreference_unlocked(&obj->base); + return ret; } static int -- 1.9.3 ^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: [PATCH v4 5/5] drm/i915: remove intel_crtc_cursor_set_obj() 2014-10-24 13:51 ` [PATCH v4 5/5] drm/i915: remove intel_crtc_cursor_set_obj() Gustavo Padovan @ 2014-10-24 15:16 ` Ville Syrjälä 2014-10-28 12:02 ` Gustavo Padovan 2014-10-28 12:35 ` [Intel-gfx] " Ville Syrjälä 1 sibling, 1 reply; 24+ messages in thread From: Ville Syrjälä @ 2014-10-24 15:16 UTC (permalink / raw) To: Gustavo Padovan; +Cc: intel-gfx, Gustavo Padovan, dri-devel On Fri, Oct 24, 2014 at 02:51:35PM +0100, Gustavo Padovan wrote: > From: Gustavo Padovan <gustavo.padovan@collabora.co.uk> > > Merge it into the plane update_plane() callback and make other > users use the update_plane() functions instead. > > The fb != crtc->cursor->fb was already inside intel_crtc_cursor_set_obj() > so we fold intel_crtc_cursor_set_obj() inside intel_commit_cursor_plane() > and merge both paths into one. > > Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> > --- > drivers/gpu/drm/i915/intel_display.c | 215 ++++++++++++++++------------------- > 1 file changed, 100 insertions(+), 115 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c > index 9a913f5..60ec165 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -8453,109 +8453,6 @@ static bool cursor_size_ok(struct drm_device *dev, > return true; > } > > -static int intel_crtc_cursor_set_obj(struct drm_crtc *crtc, > - struct drm_i915_gem_object *obj, > - uint32_t width, uint32_t height) > -{ > - struct drm_device *dev = crtc->dev; > - struct drm_i915_private *dev_priv = dev->dev_private; > - struct intel_crtc *intel_crtc = to_intel_crtc(crtc); > - enum pipe pipe = intel_crtc->pipe; > - unsigned old_width; > - uint32_t addr; > - int ret; > - > - /* if we want to turn off the cursor ignore width and height */ > - if (!obj) { > - DRM_DEBUG_KMS("cursor off\n"); > - addr = 0; > - mutex_lock(&dev->struct_mutex); > - goto finish; > - } > - > - /* we only need to pin inside GTT if cursor is non-phy */ > - mutex_lock(&dev->struct_mutex); > - if (!INTEL_INFO(dev)->cursor_needs_physical) { > - unsigned alignment; > - > - /* > - * Global gtt pte registers are special registers which actually > - * forward writes to a chunk of system memory. Which means that > - * there is no risk that the register values disappear as soon > - * as we call intel_runtime_pm_put(), so it is correct to wrap > - * only the pin/unpin/fence and not more. > - */ > - intel_runtime_pm_get(dev_priv); > - > - /* Note that the w/a also requires 2 PTE of padding following > - * the bo. We currently fill all unused PTE with the shadow > - * page and so we should always have valid PTE following the > - * cursor preventing the VT-d warning. > - */ > - alignment = 0; > - if (need_vtd_wa(dev)) > - alignment = 64*1024; > - > - ret = i915_gem_object_pin_to_display_plane(obj, alignment, NULL); > - if (ret) { > - DRM_DEBUG_KMS("failed to move cursor bo into the GTT\n"); > - intel_runtime_pm_put(dev_priv); > - goto fail_locked; > - } > - > - ret = i915_gem_object_put_fence(obj); > - if (ret) { > - DRM_DEBUG_KMS("failed to release fence for cursor"); > - intel_runtime_pm_put(dev_priv); > - goto fail_unpin; > - } > - > - addr = i915_gem_obj_ggtt_offset(obj); > - > - intel_runtime_pm_put(dev_priv); > - } else { > - int align = IS_I830(dev) ? 16 * 1024 : 256; > - ret = i915_gem_object_attach_phys(obj, align); > - if (ret) { > - DRM_DEBUG_KMS("failed to attach phys object\n"); > - goto fail_locked; > - } > - addr = obj->phys_handle->busaddr; > - } > - > - finish: > - if (intel_crtc->cursor_bo) { > - if (!INTEL_INFO(dev)->cursor_needs_physical) > - i915_gem_object_unpin_from_display_plane(intel_crtc->cursor_bo); > - } > - > - i915_gem_track_fb(intel_crtc->cursor_bo, obj, > - INTEL_FRONTBUFFER_CURSOR(pipe)); > - mutex_unlock(&dev->struct_mutex); > - > - old_width = intel_crtc->cursor_width; > - > - intel_crtc->cursor_addr = addr; > - intel_crtc->cursor_bo = obj; > - intel_crtc->cursor_width = width; > - intel_crtc->cursor_height = height; > - > - if (intel_crtc->active) { > - if (old_width != width) > - intel_update_watermarks(crtc); > - intel_crtc_update_cursor(crtc, intel_crtc->cursor_bo != NULL); > - > - intel_frontbuffer_flip(dev, INTEL_FRONTBUFFER_CURSOR(pipe)); > - } > - > - return 0; > -fail_unpin: > - i915_gem_object_unpin_from_display_plane(obj); > -fail_locked: > - mutex_unlock(&dev->struct_mutex); > - return ret; > -} > - > static void intel_crtc_gamma_set(struct drm_crtc *crtc, u16 *red, u16 *green, > u16 *blue, uint32_t start, uint32_t size) > { > @@ -11906,7 +11803,8 @@ intel_cursor_plane_disable(struct drm_plane *plane) > > BUG_ON(!plane->crtc); > > - return intel_crtc_cursor_set_obj(plane->crtc, NULL, 0, 0); > + return plane->funcs->update_plane(plane, plane->crtc, NULL, > + 0, 0, 0, 0, 0, 0, 0, 0); > } > > static int > @@ -11970,26 +11868,113 @@ intel_commit_cursor_plane(struct drm_plane *plane, > struct intel_plane_state *state) > { > struct drm_crtc *crtc = state->crtc; > + struct drm_device *dev = crtc->dev; > + struct drm_i915_private *dev_priv = dev->dev_private; > struct drm_framebuffer *fb = state->fb; > struct intel_crtc *intel_crtc = to_intel_crtc(crtc); > - struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb); > - struct drm_i915_gem_object *obj = intel_fb->obj; > - int crtc_w, crtc_h; > + struct drm_i915_gem_object *obj = intel_fb_obj(fb); > + enum pipe pipe = intel_crtc->pipe; > + unsigned old_width; > + uint32_t addr; > + int ret; > > crtc->cursor_x = state->orig_dst.x1; > crtc->cursor_y = state->orig_dst.y1; > - if (fb != crtc->cursor->fb) { > - crtc_w = drm_rect_width(&state->orig_dst); > - crtc_h = drm_rect_height(&state->orig_dst); > - return intel_crtc_cursor_set_obj(crtc, obj, crtc_w, crtc_h); > + > + if (intel_crtc->cursor_bo == obj) > + goto update; > + > + /* if we want to turn off the cursor ignore width and height */ > + if (!obj) { > + DRM_DEBUG_KMS("cursor off\n"); > + addr = 0; > + mutex_lock(&dev->struct_mutex); > + goto finish; > + } > + > + /* we only need to pin inside GTT if cursor is non-phy */ > + mutex_lock(&dev->struct_mutex); > + if (!INTEL_INFO(dev)->cursor_needs_physical) { > + unsigned alignment; > + > + /* > + * Global gtt pte registers are special registers which actually > + * forward writes to a chunk of system memory. Which means that > + * there is no risk that the register values disappear as soon > + * as we call intel_runtime_pm_put(), so it is correct to wrap > + * only the pin/unpin/fence and not more. > + */ > + intel_runtime_pm_get(dev_priv); > + > + /* Note that the w/a also requires 2 PTE of padding following > + * the bo. We currently fill all unused PTE with the shadow > + * page and so we should always have valid PTE following the > + * cursor preventing the VT-d warning. > + */ > + alignment = 0; > + if (need_vtd_wa(dev)) > + alignment = 64*1024; > + > + ret = i915_gem_object_pin_to_display_plane(obj, alignment, NULL); > + if (ret) { > + DRM_DEBUG_KMS("failed to move cursor bo into the GTT\n"); > + intel_runtime_pm_put(dev_priv); > + goto fail_locked; > + } > + > + ret = i915_gem_object_put_fence(obj); > + if (ret) { > + DRM_DEBUG_KMS("failed to release fence for cursor"); > + intel_runtime_pm_put(dev_priv); > + goto fail_unpin; > + } > + > + addr = i915_gem_obj_ggtt_offset(obj); > + > + intel_runtime_pm_put(dev_priv); > } else { > - intel_crtc_update_cursor(crtc, state->visible); > + int align = IS_I830(dev) ? 16 * 1024 : 256; > + ret = i915_gem_object_attach_phys(obj, align); > + if (ret) { > + DRM_DEBUG_KMS("failed to attach phys object\n"); > + goto fail_locked; > + } > + addr = obj->phys_handle->busaddr; > + } > > - intel_frontbuffer_flip(crtc->dev, > - INTEL_FRONTBUFFER_CURSOR(intel_crtc->pipe)); > +finish: > + if (intel_crtc->cursor_bo) { > + if (!INTEL_INFO(dev)->cursor_needs_physical) > + i915_gem_object_unpin_from_display_plane(intel_crtc->cursor_bo); > + } > > - return 0; > + i915_gem_track_fb(intel_crtc->cursor_bo, obj, > + INTEL_FRONTBUFFER_CURSOR(pipe)); > + mutex_unlock(&dev->struct_mutex); > + > + intel_crtc->cursor_addr = addr; > + intel_crtc->cursor_bo = obj; > +update: > + old_width = intel_crtc->cursor_width; > + > + intel_crtc->cursor_width = drm_rect_width(&state->orig_dst); > + intel_crtc->cursor_height = drm_rect_height(&state->orig_dst); > + > + if (intel_crtc->active) { > + if (old_width != intel_crtc->cursor_width) > + intel_update_watermarks(crtc); > + intel_crtc_update_cursor(crtc, state->visible); So we need to make sure state->visible==false when there's no fb. I suppose we should just do that in drm_plane_helper_check_update(). > + > + intel_frontbuffer_flip(dev, INTEL_FRONTBUFFER_CURSOR(pipe)); > } > + > + return 0; > +fail_unpin: > + i915_gem_object_unpin_from_display_plane(obj); > +fail_locked: > + mutex_unlock(&dev->struct_mutex); > + drm_gem_object_unreference_unlocked(&obj->base); > + return ret; > } > > static int > -- > 1.9.3 > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ville Syrjälä Intel OTC ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v4 5/5] drm/i915: remove intel_crtc_cursor_set_obj() 2014-10-24 15:16 ` Ville Syrjälä @ 2014-10-28 12:02 ` Gustavo Padovan 0 siblings, 0 replies; 24+ messages in thread From: Gustavo Padovan @ 2014-10-28 12:02 UTC (permalink / raw) To: Ville Syrjälä; +Cc: intel-gfx, dri-devel Hi Ville, 2014-10-24 Ville Syrjälä <ville.syrjala@linux.intel.com>: > On Fri, Oct 24, 2014 at 02:51:35PM +0100, Gustavo Padovan wrote: > > From: Gustavo Padovan <gustavo.padovan@collabora.co.uk> > > > > Merge it into the plane update_plane() callback and make other > > users use the update_plane() functions instead. > > > > The fb != crtc->cursor->fb was already inside intel_crtc_cursor_set_obj() > > so we fold intel_crtc_cursor_set_obj() inside intel_commit_cursor_plane() > > and merge both paths into one. > > > > Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> > > --- > > drivers/gpu/drm/i915/intel_display.c | 215 ++++++++++++++++------------------- > > 1 file changed, 100 insertions(+), 115 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c > > index 9a913f5..60ec165 100644 > > --- a/drivers/gpu/drm/i915/intel_display.c > > +++ b/drivers/gpu/drm/i915/intel_display.c > > @@ -8453,109 +8453,6 @@ static bool cursor_size_ok(struct drm_device *dev, > > return true; > > } > > > > -static int intel_crtc_cursor_set_obj(struct drm_crtc *crtc, > > - struct drm_i915_gem_object *obj, > > - uint32_t width, uint32_t height) > > -{ > > - struct drm_device *dev = crtc->dev; > > - struct drm_i915_private *dev_priv = dev->dev_private; > > - struct intel_crtc *intel_crtc = to_intel_crtc(crtc); > > - enum pipe pipe = intel_crtc->pipe; > > - unsigned old_width; > > - uint32_t addr; > > - int ret; > > - > > - /* if we want to turn off the cursor ignore width and height */ > > - if (!obj) { > > - DRM_DEBUG_KMS("cursor off\n"); > > - addr = 0; > > - mutex_lock(&dev->struct_mutex); > > - goto finish; > > - } > > - > > - /* we only need to pin inside GTT if cursor is non-phy */ > > - mutex_lock(&dev->struct_mutex); > > - if (!INTEL_INFO(dev)->cursor_needs_physical) { > > - unsigned alignment; > > - > > - /* > > - * Global gtt pte registers are special registers which actually > > - * forward writes to a chunk of system memory. Which means that > > - * there is no risk that the register values disappear as soon > > - * as we call intel_runtime_pm_put(), so it is correct to wrap > > - * only the pin/unpin/fence and not more. > > - */ > > - intel_runtime_pm_get(dev_priv); > > - > > - /* Note that the w/a also requires 2 PTE of padding following > > - * the bo. We currently fill all unused PTE with the shadow > > - * page and so we should always have valid PTE following the > > - * cursor preventing the VT-d warning. > > - */ > > - alignment = 0; > > - if (need_vtd_wa(dev)) > > - alignment = 64*1024; > > - > > - ret = i915_gem_object_pin_to_display_plane(obj, alignment, NULL); > > - if (ret) { > > - DRM_DEBUG_KMS("failed to move cursor bo into the GTT\n"); > > - intel_runtime_pm_put(dev_priv); > > - goto fail_locked; > > - } > > - > > - ret = i915_gem_object_put_fence(obj); > > - if (ret) { > > - DRM_DEBUG_KMS("failed to release fence for cursor"); > > - intel_runtime_pm_put(dev_priv); > > - goto fail_unpin; > > - } > > - > > - addr = i915_gem_obj_ggtt_offset(obj); > > - > > - intel_runtime_pm_put(dev_priv); > > - } else { > > - int align = IS_I830(dev) ? 16 * 1024 : 256; > > - ret = i915_gem_object_attach_phys(obj, align); > > - if (ret) { > > - DRM_DEBUG_KMS("failed to attach phys object\n"); > > - goto fail_locked; > > - } > > - addr = obj->phys_handle->busaddr; > > - } > > - > > - finish: > > - if (intel_crtc->cursor_bo) { > > - if (!INTEL_INFO(dev)->cursor_needs_physical) > > - i915_gem_object_unpin_from_display_plane(intel_crtc->cursor_bo); > > - } > > - > > - i915_gem_track_fb(intel_crtc->cursor_bo, obj, > > - INTEL_FRONTBUFFER_CURSOR(pipe)); > > - mutex_unlock(&dev->struct_mutex); > > - > > - old_width = intel_crtc->cursor_width; > > - > > - intel_crtc->cursor_addr = addr; > > - intel_crtc->cursor_bo = obj; > > - intel_crtc->cursor_width = width; > > - intel_crtc->cursor_height = height; > > - > > - if (intel_crtc->active) { > > - if (old_width != width) > > - intel_update_watermarks(crtc); > > - intel_crtc_update_cursor(crtc, intel_crtc->cursor_bo != NULL); > > - > > - intel_frontbuffer_flip(dev, INTEL_FRONTBUFFER_CURSOR(pipe)); > > - } > > - > > - return 0; > > -fail_unpin: > > - i915_gem_object_unpin_from_display_plane(obj); > > -fail_locked: > > - mutex_unlock(&dev->struct_mutex); > > - return ret; > > -} > > - > > static void intel_crtc_gamma_set(struct drm_crtc *crtc, u16 *red, u16 *green, > > u16 *blue, uint32_t start, uint32_t size) > > { > > @@ -11906,7 +11803,8 @@ intel_cursor_plane_disable(struct drm_plane *plane) > > > > BUG_ON(!plane->crtc); > > > > - return intel_crtc_cursor_set_obj(plane->crtc, NULL, 0, 0); > > + return plane->funcs->update_plane(plane, plane->crtc, NULL, > > + 0, 0, 0, 0, 0, 0, 0, 0); > > } > > > > static int > > @@ -11970,26 +11868,113 @@ intel_commit_cursor_plane(struct drm_plane *plane, > > struct intel_plane_state *state) > > { > > struct drm_crtc *crtc = state->crtc; > > + struct drm_device *dev = crtc->dev; > > + struct drm_i915_private *dev_priv = dev->dev_private; > > struct drm_framebuffer *fb = state->fb; > > struct intel_crtc *intel_crtc = to_intel_crtc(crtc); > > - struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb); > > - struct drm_i915_gem_object *obj = intel_fb->obj; > > - int crtc_w, crtc_h; > > + struct drm_i915_gem_object *obj = intel_fb_obj(fb); > > + enum pipe pipe = intel_crtc->pipe; > > + unsigned old_width; > > + uint32_t addr; > > + int ret; > > > > crtc->cursor_x = state->orig_dst.x1; > > crtc->cursor_y = state->orig_dst.y1; > > - if (fb != crtc->cursor->fb) { > > - crtc_w = drm_rect_width(&state->orig_dst); > > - crtc_h = drm_rect_height(&state->orig_dst); > > - return intel_crtc_cursor_set_obj(crtc, obj, crtc_w, crtc_h); > > + > > + if (intel_crtc->cursor_bo == obj) > > + goto update; > > + > > + /* if we want to turn off the cursor ignore width and height */ > > + if (!obj) { > > + DRM_DEBUG_KMS("cursor off\n"); > > + addr = 0; > > + mutex_lock(&dev->struct_mutex); > > + goto finish; > > + } > > + > > + /* we only need to pin inside GTT if cursor is non-phy */ > > + mutex_lock(&dev->struct_mutex); > > + if (!INTEL_INFO(dev)->cursor_needs_physical) { > > + unsigned alignment; > > + > > + /* > > + * Global gtt pte registers are special registers which actually > > + * forward writes to a chunk of system memory. Which means that > > + * there is no risk that the register values disappear as soon > > + * as we call intel_runtime_pm_put(), so it is correct to wrap > > + * only the pin/unpin/fence and not more. > > + */ > > + intel_runtime_pm_get(dev_priv); > > + > > + /* Note that the w/a also requires 2 PTE of padding following > > + * the bo. We currently fill all unused PTE with the shadow > > + * page and so we should always have valid PTE following the > > + * cursor preventing the VT-d warning. > > + */ > > + alignment = 0; > > + if (need_vtd_wa(dev)) > > + alignment = 64*1024; > > + > > + ret = i915_gem_object_pin_to_display_plane(obj, alignment, NULL); > > + if (ret) { > > + DRM_DEBUG_KMS("failed to move cursor bo into the GTT\n"); > > + intel_runtime_pm_put(dev_priv); > > + goto fail_locked; > > + } > > + > > + ret = i915_gem_object_put_fence(obj); > > + if (ret) { > > + DRM_DEBUG_KMS("failed to release fence for cursor"); > > + intel_runtime_pm_put(dev_priv); > > + goto fail_unpin; > > + } > > + > > + addr = i915_gem_obj_ggtt_offset(obj); > > + > > + intel_runtime_pm_put(dev_priv); > > } else { > > - intel_crtc_update_cursor(crtc, state->visible); > > + int align = IS_I830(dev) ? 16 * 1024 : 256; > > + ret = i915_gem_object_attach_phys(obj, align); > > + if (ret) { > > + DRM_DEBUG_KMS("failed to attach phys object\n"); > > + goto fail_locked; > > + } > > + addr = obj->phys_handle->busaddr; > > + } > > > > - intel_frontbuffer_flip(crtc->dev, > > - INTEL_FRONTBUFFER_CURSOR(intel_crtc->pipe)); > > +finish: > > + if (intel_crtc->cursor_bo) { > > + if (!INTEL_INFO(dev)->cursor_needs_physical) > > + i915_gem_object_unpin_from_display_plane(intel_crtc->cursor_bo); > > + } > > > > - return 0; > > + i915_gem_track_fb(intel_crtc->cursor_bo, obj, > > + INTEL_FRONTBUFFER_CURSOR(pipe)); > > + mutex_unlock(&dev->struct_mutex); > > + > > + intel_crtc->cursor_addr = addr; > > + intel_crtc->cursor_bo = obj; > > +update: > > + old_width = intel_crtc->cursor_width; > > + > > + intel_crtc->cursor_width = drm_rect_width(&state->orig_dst); > > + intel_crtc->cursor_height = drm_rect_height(&state->orig_dst); > > + > > + if (intel_crtc->active) { > > + if (old_width != intel_crtc->cursor_width) > > + intel_update_watermarks(crtc); > > + intel_crtc_update_cursor(crtc, state->visible); > > So we need to make sure state->visible==false when there's no fb. I > suppose we should just do that in drm_plane_helper_check_update(). The code to check that is merged already, do you have any other comment on this patch? Gustavo _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Intel-gfx] [PATCH v4 5/5] drm/i915: remove intel_crtc_cursor_set_obj() 2014-10-24 13:51 ` [PATCH v4 5/5] drm/i915: remove intel_crtc_cursor_set_obj() Gustavo Padovan 2014-10-24 15:16 ` Ville Syrjälä @ 2014-10-28 12:35 ` Ville Syrjälä 1 sibling, 0 replies; 24+ messages in thread From: Ville Syrjälä @ 2014-10-28 12:35 UTC (permalink / raw) To: Gustavo Padovan; +Cc: intel-gfx, Gustavo Padovan, dri-devel On Fri, Oct 24, 2014 at 02:51:35PM +0100, Gustavo Padovan wrote: > From: Gustavo Padovan <gustavo.padovan@collabora.co.uk> > > Merge it into the plane update_plane() callback and make other > users use the update_plane() functions instead. > > The fb != crtc->cursor->fb was already inside intel_crtc_cursor_set_obj() > so we fold intel_crtc_cursor_set_obj() inside intel_commit_cursor_plane() > and merge both paths into one. > > Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> > --- > drivers/gpu/drm/i915/intel_display.c | 215 ++++++++++++++++------------------- > 1 file changed, 100 insertions(+), 115 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c > index 9a913f5..60ec165 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -8453,109 +8453,6 @@ static bool cursor_size_ok(struct drm_device *dev, > return true; > } > > -static int intel_crtc_cursor_set_obj(struct drm_crtc *crtc, > - struct drm_i915_gem_object *obj, > - uint32_t width, uint32_t height) > -{ > - struct drm_device *dev = crtc->dev; > - struct drm_i915_private *dev_priv = dev->dev_private; > - struct intel_crtc *intel_crtc = to_intel_crtc(crtc); > - enum pipe pipe = intel_crtc->pipe; > - unsigned old_width; > - uint32_t addr; > - int ret; > - > - /* if we want to turn off the cursor ignore width and height */ > - if (!obj) { > - DRM_DEBUG_KMS("cursor off\n"); > - addr = 0; > - mutex_lock(&dev->struct_mutex); > - goto finish; > - } > - > - /* we only need to pin inside GTT if cursor is non-phy */ > - mutex_lock(&dev->struct_mutex); > - if (!INTEL_INFO(dev)->cursor_needs_physical) { > - unsigned alignment; > - > - /* > - * Global gtt pte registers are special registers which actually > - * forward writes to a chunk of system memory. Which means that > - * there is no risk that the register values disappear as soon > - * as we call intel_runtime_pm_put(), so it is correct to wrap > - * only the pin/unpin/fence and not more. > - */ > - intel_runtime_pm_get(dev_priv); > - > - /* Note that the w/a also requires 2 PTE of padding following > - * the bo. We currently fill all unused PTE with the shadow > - * page and so we should always have valid PTE following the > - * cursor preventing the VT-d warning. > - */ > - alignment = 0; > - if (need_vtd_wa(dev)) > - alignment = 64*1024; > - > - ret = i915_gem_object_pin_to_display_plane(obj, alignment, NULL); > - if (ret) { > - DRM_DEBUG_KMS("failed to move cursor bo into the GTT\n"); > - intel_runtime_pm_put(dev_priv); > - goto fail_locked; > - } > - > - ret = i915_gem_object_put_fence(obj); > - if (ret) { > - DRM_DEBUG_KMS("failed to release fence for cursor"); > - intel_runtime_pm_put(dev_priv); > - goto fail_unpin; > - } > - > - addr = i915_gem_obj_ggtt_offset(obj); > - > - intel_runtime_pm_put(dev_priv); > - } else { > - int align = IS_I830(dev) ? 16 * 1024 : 256; > - ret = i915_gem_object_attach_phys(obj, align); > - if (ret) { > - DRM_DEBUG_KMS("failed to attach phys object\n"); > - goto fail_locked; > - } > - addr = obj->phys_handle->busaddr; > - } > - > - finish: > - if (intel_crtc->cursor_bo) { > - if (!INTEL_INFO(dev)->cursor_needs_physical) > - i915_gem_object_unpin_from_display_plane(intel_crtc->cursor_bo); > - } > - > - i915_gem_track_fb(intel_crtc->cursor_bo, obj, > - INTEL_FRONTBUFFER_CURSOR(pipe)); > - mutex_unlock(&dev->struct_mutex); > - > - old_width = intel_crtc->cursor_width; > - > - intel_crtc->cursor_addr = addr; > - intel_crtc->cursor_bo = obj; > - intel_crtc->cursor_width = width; > - intel_crtc->cursor_height = height; > - > - if (intel_crtc->active) { > - if (old_width != width) > - intel_update_watermarks(crtc); > - intel_crtc_update_cursor(crtc, intel_crtc->cursor_bo != NULL); > - > - intel_frontbuffer_flip(dev, INTEL_FRONTBUFFER_CURSOR(pipe)); > - } > - > - return 0; > -fail_unpin: > - i915_gem_object_unpin_from_display_plane(obj); > -fail_locked: > - mutex_unlock(&dev->struct_mutex); > - return ret; > -} > - > static void intel_crtc_gamma_set(struct drm_crtc *crtc, u16 *red, u16 *green, > u16 *blue, uint32_t start, uint32_t size) > { > @@ -11906,7 +11803,8 @@ intel_cursor_plane_disable(struct drm_plane *plane) > > BUG_ON(!plane->crtc); > > - return intel_crtc_cursor_set_obj(plane->crtc, NULL, 0, 0); > + return plane->funcs->update_plane(plane, plane->crtc, NULL, > + 0, 0, 0, 0, 0, 0, 0, 0); > } > > static int > @@ -11970,26 +11868,113 @@ intel_commit_cursor_plane(struct drm_plane *plane, > struct intel_plane_state *state) > { > struct drm_crtc *crtc = state->crtc; > + struct drm_device *dev = crtc->dev; > + struct drm_i915_private *dev_priv = dev->dev_private; > struct drm_framebuffer *fb = state->fb; > struct intel_crtc *intel_crtc = to_intel_crtc(crtc); > - struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb); > - struct drm_i915_gem_object *obj = intel_fb->obj; > - int crtc_w, crtc_h; > + struct drm_i915_gem_object *obj = intel_fb_obj(fb); > + enum pipe pipe = intel_crtc->pipe; > + unsigned old_width; > + uint32_t addr; > + int ret; > > crtc->cursor_x = state->orig_dst.x1; > crtc->cursor_y = state->orig_dst.y1; > - if (fb != crtc->cursor->fb) { > - crtc_w = drm_rect_width(&state->orig_dst); > - crtc_h = drm_rect_height(&state->orig_dst); > - return intel_crtc_cursor_set_obj(crtc, obj, crtc_w, crtc_h); > + > + if (intel_crtc->cursor_bo == obj) > + goto update; > + > + /* if we want to turn off the cursor ignore width and height */ > + if (!obj) { > + DRM_DEBUG_KMS("cursor off\n"); > + addr = 0; > + mutex_lock(&dev->struct_mutex); > + goto finish; > + } > + > + /* we only need to pin inside GTT if cursor is non-phy */ > + mutex_lock(&dev->struct_mutex); > + if (!INTEL_INFO(dev)->cursor_needs_physical) { > + unsigned alignment; > + > + /* > + * Global gtt pte registers are special registers which actually > + * forward writes to a chunk of system memory. Which means that > + * there is no risk that the register values disappear as soon > + * as we call intel_runtime_pm_put(), so it is correct to wrap > + * only the pin/unpin/fence and not more. > + */ > + intel_runtime_pm_get(dev_priv); > + > + /* Note that the w/a also requires 2 PTE of padding following > + * the bo. We currently fill all unused PTE with the shadow > + * page and so we should always have valid PTE following the > + * cursor preventing the VT-d warning. > + */ > + alignment = 0; > + if (need_vtd_wa(dev)) > + alignment = 64*1024; > + > + ret = i915_gem_object_pin_to_display_plane(obj, alignment, NULL); > + if (ret) { > + DRM_DEBUG_KMS("failed to move cursor bo into the GTT\n"); > + intel_runtime_pm_put(dev_priv); > + goto fail_locked; > + } > + > + ret = i915_gem_object_put_fence(obj); > + if (ret) { > + DRM_DEBUG_KMS("failed to release fence for cursor"); > + intel_runtime_pm_put(dev_priv); > + goto fail_unpin; > + } > + > + addr = i915_gem_obj_ggtt_offset(obj); > + > + intel_runtime_pm_put(dev_priv); > } else { > - intel_crtc_update_cursor(crtc, state->visible); > + int align = IS_I830(dev) ? 16 * 1024 : 256; > + ret = i915_gem_object_attach_phys(obj, align); > + if (ret) { > + DRM_DEBUG_KMS("failed to attach phys object\n"); > + goto fail_locked; > + } > + addr = obj->phys_handle->busaddr; > + } > > - intel_frontbuffer_flip(crtc->dev, > - INTEL_FRONTBUFFER_CURSOR(intel_crtc->pipe)); > +finish: > + if (intel_crtc->cursor_bo) { > + if (!INTEL_INFO(dev)->cursor_needs_physical) > + i915_gem_object_unpin_from_display_plane(intel_crtc->cursor_bo); > + } > > - return 0; > + i915_gem_track_fb(intel_crtc->cursor_bo, obj, > + INTEL_FRONTBUFFER_CURSOR(pipe)); > + mutex_unlock(&dev->struct_mutex); > + > + intel_crtc->cursor_addr = addr; > + intel_crtc->cursor_bo = obj; > +update: > + old_width = intel_crtc->cursor_width; > + > + intel_crtc->cursor_width = drm_rect_width(&state->orig_dst); > + intel_crtc->cursor_height = drm_rect_height(&state->orig_dst); > + > + if (intel_crtc->active) { > + if (old_width != intel_crtc->cursor_width) > + intel_update_watermarks(crtc); > + intel_crtc_update_cursor(crtc, state->visible); > + > + intel_frontbuffer_flip(dev, INTEL_FRONTBUFFER_CURSOR(pipe)); > } > + > + return 0; > +fail_unpin: > + i915_gem_object_unpin_from_display_plane(obj); > +fail_locked: > + mutex_unlock(&dev->struct_mutex); > + drm_gem_object_unreference_unlocked(&obj->base); That unref needs to be dropped. With that change the patch is Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> > + return ret; > } > > static int > -- > 1.9.3 > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ville Syrjälä Intel OTC _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2014-11-12 14:45 UTC | newest] Thread overview: 24+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-10-24 13:51 [PATCH v4 1/5] drm/i915: create a prepare step for primary planes updates Gustavo Padovan 2014-10-24 13:51 ` [PATCH v4 2/5] drm/i915: create a prepare phase for sprite plane updates Gustavo Padovan 2014-10-30 13:32 ` Paulo Zanoni 2014-10-30 14:08 ` [Intel-gfx] " Imre Deak 2014-10-30 14:34 ` Ville Syrjälä 2014-10-30 18:02 ` [PATCH] drm/i915: use the correct obj when preparing the sprite plane Paulo Zanoni 2014-10-30 19:10 ` Ville Syrjälä 2014-10-30 19:33 ` Paulo Zanoni 2014-11-10 16:47 ` Paulo Zanoni 2014-11-10 17:15 ` Ville Syrjälä 2014-11-11 9:30 ` How to handle planes/fbs when disabling the crtc? (was Re: [Intel-gfx] [PATCH] drm/i915: use the correct obj when preparing the sprite plane) Daniel Vetter 2014-11-12 11:49 ` Ville Syrjälä 2014-11-12 14:22 ` How to handle planes/fbs when disabling the crtc? (was " Daniel Vetter 2014-11-12 14:45 ` Ville Syrjälä 2014-11-11 9:31 ` [PATCH] drm/i915: use the correct obj when preparing the sprite plane Daniel Vetter 2014-11-11 8:41 ` [PATCH] drm/i915: use the correct obj when preparing shuang.he 2014-10-24 13:51 ` [PATCH v4 3/5] drm/i915: use intel_fb_obj() macros to assign gem objects Gustavo Padovan 2014-10-24 13:51 ` [PATCH v4 4/5] drm/i915: only flip frontbuffer if crtc is active Gustavo Padovan 2014-10-24 15:07 ` Ville Syrjälä 2014-10-27 9:10 ` Daniel Vetter 2014-10-24 13:51 ` [PATCH v4 5/5] drm/i915: remove intel_crtc_cursor_set_obj() Gustavo Padovan 2014-10-24 15:16 ` Ville Syrjälä 2014-10-28 12:02 ` Gustavo Padovan 2014-10-28 12:35 ` [Intel-gfx] " Ville Syrjälä
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox