All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>,
	dri-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org,
	Kieran Bingham <kieran.bingham@ideasonboard.com>
Subject: Re: [PATCH v2] drm: rcar-du: Arm the page flip event after queuing the page flip
Date: Mon, 06 Mar 2017 17:11:17 +0200	[thread overview]
Message-ID: <1783628.YCkISaBNKo@avalon> (raw)
In-Reply-To: <20170306150200.wpl3ya6kcybgtpij@phenom.ffwll.local>

Hi Daniel,

On Monday 06 Mar 2017 16:02:00 Daniel Vetter wrote:
> On Sun, Mar 05, 2017 at 03:10:32AM +0200, Laurent Pinchart wrote:
> > The page flip event is armed in the atomic begin handler, creating a
> > race condition with the frame end interrupt that could send the event
> > before the atomic operation actually completes. To avoid that, arm the
> > event in the atomic flush handler after queuing the page flip.
> > 
> > This change doesn't fully close the race window, as the frame end
> > interrupt could be generated before the page flip is committed to
> > hardware but only handled after the event is armed. However, the race
> > window is now much smaller.
> > 
> > The event must however be armed before calling the VSP atomic commit
> > function, otherwise the completion callback could arrive before we arm
> > the event, resulting in a deadlock.
> > 
> > Signed-off-by: Laurent Pinchart
> > <laurent.pinchart+renesas@ideasonboard.com>
> 
> Since your hw is not the only one where this seems fundamentally
> unfixable, should we document a recommended way to handle/minize the race
> window?

Sure, that's a good idea.

I think it boils down to one of those two options:

- If the device can notify of page flip completion, the event should be armed 
just before the page flip is committed. At the hardware level this can be as 
simple as an interrupt that will only be fired when a queued page flip is 
processed (and not at every vblank), or a combination of a GO bit with vblank 
(which then requires a more complex dance). The R-Car Gen3 hardware falls in 
this category, the external VSP compositor that handles planes has a GO bit 
and a vblank-like interrupt.

- If the device can't notify of page flip completion, the event should be 
armed just after the page flip is committed. In the worst case the driver will 
send the event to userspace one frame too late. This doesn't allow for a real 
atomic update, but it should avoid tearing. The R-Car Gen2 hardware falls in 
this category.

Feel free to turn this into a kerneldoc patch :-)

> > ---
> > 
> >  drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 22 +++++++++++-----------
> >  1 file changed, 11 insertions(+), 11 deletions(-)
> > 
> > Changes since v1:
> > 
> > - Arm the event before calling the VSP atomic commit function
> > 
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c index 7391dd95c733..2aceb84fc15d
> > 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> > @@ -502,17 +502,6 @@ static void rcar_du_crtc_atomic_begin(struct drm_crtc
> > *crtc,> 
> >  				      struct drm_crtc_state *old_crtc_state)
> >  
> >  {
> >  
> >  	struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
> > 
> > -	struct drm_device *dev = rcrtc->crtc.dev;
> > -	unsigned long flags;
> > -
> > -	if (crtc->state->event) {
> > -		WARN_ON(drm_crtc_vblank_get(crtc) != 0);
> > -
> > -		spin_lock_irqsave(&dev->event_lock, flags);
> > -		rcrtc->event = crtc->state->event;
> > -		crtc->state->event = NULL;
> > -		spin_unlock_irqrestore(&dev->event_lock, flags);
> > -	}
> > 
> >  	if (rcar_du_has(rcrtc->group->dev, RCAR_DU_FEATURE_VSP1_SOURCE))
> >  	
> >  		rcar_du_vsp_atomic_begin(rcrtc);
> > 
> > @@ -522,9 +511,20 @@ static void rcar_du_crtc_atomic_flush(struct drm_crtc
> > *crtc,> 
> >  				      struct drm_crtc_state *old_crtc_state)
> >  
> >  {
> >  
> >  	struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
> > 
> > +	struct drm_device *dev = rcrtc->crtc.dev;
> > +	unsigned long flags;
> > 
> >  	rcar_du_crtc_update_planes(rcrtc);
> > 
> > +	if (crtc->state->event) {
> > +		WARN_ON(drm_crtc_vblank_get(crtc) != 0);
> > +
> > +		spin_lock_irqsave(&dev->event_lock, flags);
> > +		rcrtc->event = crtc->state->event;
> > +		crtc->state->event = NULL;
> > +		spin_unlock_irqrestore(&dev->event_lock, flags);
> > +	}
> > +
> > 
> >  	if (rcar_du_has(rcrtc->group->dev, RCAR_DU_FEATURE_VSP1_SOURCE))
> >  	
> >  		rcar_du_vsp_atomic_flush(rcrtc);
> >  
> >  }

-- 
Regards,

Laurent Pinchart

WARNING: multiple messages have this Message-ID (diff)
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: linux-renesas-soc@vger.kernel.org,
	Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>,
	Kieran Bingham <kieran.bingham@ideasonboard.com>,
	dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v2] drm: rcar-du: Arm the page flip event after queuing the page flip
Date: Mon, 06 Mar 2017 17:11:17 +0200	[thread overview]
Message-ID: <1783628.YCkISaBNKo@avalon> (raw)
In-Reply-To: <20170306150200.wpl3ya6kcybgtpij@phenom.ffwll.local>

Hi Daniel,

On Monday 06 Mar 2017 16:02:00 Daniel Vetter wrote:
> On Sun, Mar 05, 2017 at 03:10:32AM +0200, Laurent Pinchart wrote:
> > The page flip event is armed in the atomic begin handler, creating a
> > race condition with the frame end interrupt that could send the event
> > before the atomic operation actually completes. To avoid that, arm the
> > event in the atomic flush handler after queuing the page flip.
> > 
> > This change doesn't fully close the race window, as the frame end
> > interrupt could be generated before the page flip is committed to
> > hardware but only handled after the event is armed. However, the race
> > window is now much smaller.
> > 
> > The event must however be armed before calling the VSP atomic commit
> > function, otherwise the completion callback could arrive before we arm
> > the event, resulting in a deadlock.
> > 
> > Signed-off-by: Laurent Pinchart
> > <laurent.pinchart+renesas@ideasonboard.com>
> 
> Since your hw is not the only one where this seems fundamentally
> unfixable, should we document a recommended way to handle/minize the race
> window?

Sure, that's a good idea.

I think it boils down to one of those two options:

- If the device can notify of page flip completion, the event should be armed 
just before the page flip is committed. At the hardware level this can be as 
simple as an interrupt that will only be fired when a queued page flip is 
processed (and not at every vblank), or a combination of a GO bit with vblank 
(which then requires a more complex dance). The R-Car Gen3 hardware falls in 
this category, the external VSP compositor that handles planes has a GO bit 
and a vblank-like interrupt.

- If the device can't notify of page flip completion, the event should be 
armed just after the page flip is committed. In the worst case the driver will 
send the event to userspace one frame too late. This doesn't allow for a real 
atomic update, but it should avoid tearing. The R-Car Gen2 hardware falls in 
this category.

Feel free to turn this into a kerneldoc patch :-)

> > ---
> > 
> >  drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 22 +++++++++++-----------
> >  1 file changed, 11 insertions(+), 11 deletions(-)
> > 
> > Changes since v1:
> > 
> > - Arm the event before calling the VSP atomic commit function
> > 
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c index 7391dd95c733..2aceb84fc15d
> > 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> > @@ -502,17 +502,6 @@ static void rcar_du_crtc_atomic_begin(struct drm_crtc
> > *crtc,> 
> >  				      struct drm_crtc_state *old_crtc_state)
> >  
> >  {
> >  
> >  	struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
> > 
> > -	struct drm_device *dev = rcrtc->crtc.dev;
> > -	unsigned long flags;
> > -
> > -	if (crtc->state->event) {
> > -		WARN_ON(drm_crtc_vblank_get(crtc) != 0);
> > -
> > -		spin_lock_irqsave(&dev->event_lock, flags);
> > -		rcrtc->event = crtc->state->event;
> > -		crtc->state->event = NULL;
> > -		spin_unlock_irqrestore(&dev->event_lock, flags);
> > -	}
> > 
> >  	if (rcar_du_has(rcrtc->group->dev, RCAR_DU_FEATURE_VSP1_SOURCE))
> >  	
> >  		rcar_du_vsp_atomic_begin(rcrtc);
> > 
> > @@ -522,9 +511,20 @@ static void rcar_du_crtc_atomic_flush(struct drm_crtc
> > *crtc,> 
> >  				      struct drm_crtc_state *old_crtc_state)
> >  
> >  {
> >  
> >  	struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
> > 
> > +	struct drm_device *dev = rcrtc->crtc.dev;
> > +	unsigned long flags;
> > 
> >  	rcar_du_crtc_update_planes(rcrtc);
> > 
> > +	if (crtc->state->event) {
> > +		WARN_ON(drm_crtc_vblank_get(crtc) != 0);
> > +
> > +		spin_lock_irqsave(&dev->event_lock, flags);
> > +		rcrtc->event = crtc->state->event;
> > +		crtc->state->event = NULL;
> > +		spin_unlock_irqrestore(&dev->event_lock, flags);
> > +	}
> > +
> > 
> >  	if (rcar_du_has(rcrtc->group->dev, RCAR_DU_FEATURE_VSP1_SOURCE))
> >  	
> >  		rcar_du_vsp_atomic_flush(rcrtc);
> >  
> >  }

-- 
Regards,

Laurent Pinchart

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2017-03-06 15:10 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-05  1:10 [PATCH v2] drm: rcar-du: Arm the page flip event after queuing the page flip Laurent Pinchart
2017-03-05  1:10 ` Laurent Pinchart
2017-03-06 15:02 ` Daniel Vetter
2017-03-06 15:02   ` Daniel Vetter
2017-03-06 15:11   ` Laurent Pinchart [this message]
2017-03-06 15:11     ` Laurent Pinchart

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1783628.YCkISaBNKo@avalon \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=kieran.bingham@ideasonboard.com \
    --cc=laurent.pinchart+renesas@ideasonboard.com \
    --cc=linux-renesas-soc@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.