dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v4 14/22] drm: omapdrm: Keep vblank interrupt enabled while CRTC is active
Date: Thu, 15 Dec 2016 16:51:57 +0200	[thread overview]
Message-ID: <2580087.D9jCYKYxOH@avalon> (raw)
In-Reply-To: <5fd3ff5e-e9e9-85c3-d9f2-b16d3524a677@ti.com>

Hi Tomi,

On Thursday 15 Dec 2016 14:52:47 Tomi Valkeinen wrote:
> On 14/12/16 02:27, Laurent Pinchart wrote:
> > Instead of going through a complicated private IRQ registration
> > mechanism, handle the vblank interrupt activation with the standard
> > drm_crtc_vblank_get() and drm_crtc_vblank_put() mechanism. This will let
> > the DRM core keep the vblank interrupt enabled as long as needed to
> > update the frame counter.
> > 
> > Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > ---
> > 
> >  drivers/gpu/drm/omapdrm/omap_crtc.c | 38 ++++++++++++--------------------
> >  drivers/gpu/drm/omapdrm/omap_drv.h  |  1 +
> >  drivers/gpu/drm/omapdrm/omap_irq.c  |  4 +++-
> >  3 files changed, 18 insertions(+), 25 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
> > b/drivers/gpu/drm/omapdrm/omap_crtc.c index 827ac46a6d5e..1f5372042706
> > 100644
> > --- a/drivers/gpu/drm/omapdrm/omap_crtc.c
> > +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
> > @@ -36,8 +36,6 @@ struct omap_crtc {
> > 
> >  	struct videomode vm;
> > 
> > -	struct omap_drm_irq vblank_irq;
> > -
> >  	bool ignore_digit_sync_lost;
> >  	bool enabled;
> > 
> > @@ -304,25 +302,24 @@ void omap_crtc_error_irq(struct drm_crtc *crtc,
> > uint32_t irqstatus)
> >  	DRM_ERROR_RATELIMITED("%s: errors: %08x\n", omap_crtc->name, 
irqstatus);
> >  }
> > 
> > -static void omap_crtc_vblank_irq(struct omap_drm_irq *irq, uint32_t
> > irqstatus)
> > +void omap_crtc_vblank_irq(struct drm_crtc *crtc)
> >  {
> > -	struct omap_crtc *omap_crtc =
> > -			container_of(irq, struct omap_crtc, vblank_irq);
> > -	struct drm_device *dev = omap_crtc->base.dev;
> > -	struct drm_crtc *crtc = &omap_crtc->base;
> > +	struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
> > +	bool pending;
> > 
> >  	if (dispc_mgr_go_busy(omap_crtc->channel))
> >  		return;
> >  	
> >  	DBG("%s: apply done", omap_crtc->name);
> > 
> > -	__omap_irq_unregister(dev, &omap_crtc->vblank_irq);
> > -
> >  	spin_lock(&crtc->dev->event_lock);
> > 
> > -	WARN_ON(!omap_crtc->pending);
> > +	pending = omap_crtc->pending;
> > 
> >  	omap_crtc->pending = false;
> >  	spin_unlock(&crtc->dev->event_lock);
> > 
> > +	if (pending)
> > +		drm_crtc_vblank_put(crtc);
> > +
> 
> I think there's a race.
> 
> - irq: we get vblank irq
> - irq: GO is not set, so dispc_mgr_go_busy() check doesn't trigger
> - flush: we set GO
> - flush: we lock event_lock and set the pending & event, and unlock
> - irq: irq handler continues, sees pending and event, and thinks that
> the config has been taken into use, but in reality GO bit is set and
> it'll happen only on next vblank.

I think you're right. I'll try to fix it.

> >  	/* wake up userspace */
> >  	omap_crtc_complete_page_flip(&omap_crtc->base);
> > 
> > @@ -340,8 +337,6 @@ static void omap_crtc_destroy(struct drm_crtc *crtc)
> > 
> >  	DBG("%s", omap_crtc->name);
> > 
> > -	WARN_ON(omap_crtc->vblank_irq.registered);
> > -
> >  	drm_crtc_cleanup(crtc);
> >  	
> >  	kfree(omap_crtc);
> > @@ -353,14 +348,13 @@ static void omap_crtc_enable(struct drm_crtc *crtc)
> > 
> >  	DBG("%s", omap_crtc->name);
> > 
> > +	drm_crtc_vblank_on(crtc);
> > +	WARN_ON(drm_crtc_vblank_get(crtc) != 0);
> > +
> >  	spin_lock_irq(&crtc->dev->event_lock);
> >  	WARN_ON(omap_crtc->pending);
> >  	omap_crtc->pending = true;
> >  	spin_unlock_irq(&crtc->dev->event_lock);
> > -
> > -	omap_irq_register(crtc->dev, &omap_crtc->vblank_irq);
> > -
> > -	drm_crtc_vblank_on(crtc);
> >  }
> >  
> >  static void omap_crtc_disable(struct drm_crtc *crtc)
> > @@ -414,8 +408,6 @@ static void omap_crtc_atomic_flush(struct drm_crtc
> > *crtc,
> >  {
> >  	struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
> > 
> > -	WARN_ON(omap_crtc->vblank_irq.registered);
> > -
> >  	if (crtc->state->color_mgmt_changed) {
> >  		struct drm_color_lut *lut = NULL;
> >  		uint length = 0;
> > @@ -441,6 +433,10 @@ static void omap_crtc_atomic_flush(struct drm_crtc
> > *crtc,
> > 
> >  	DBG("%s: GO", omap_crtc->name);
> > 
> > +	dispc_mgr_go(omap_crtc->channel);
> > +
> > +	WARN_ON(drm_crtc_vblank_get(crtc) != 0);
> 
> I don't like this style very much. I think WARN()s should be without
> side effects.
> 
> Also, WARN only gives benefit when we don't know what the call stack is.
> Afaik, there's only one way omap_crtc_atomic_flush can be called, so
> it's just extra spam and dev_err or dev_warn should be enough.

I've used it because the equivalent statements testing omap_crtc-
>vblank_irq.registered used WARN_ON() too. WARN_ON() is also a bit more vocal, 
it really gets the point across. As the function really should not return an 
error unless in case of a driver bug, I don't think it will generate any spam. 
I don't care too much though, I can replace it with a dev_err() if you insist.

-- 
Regards,

Laurent Pinchart

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

  reply	other threads:[~2016-12-15 14:51 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-14  0:27 [PATCH v4 00/22] OMAP DRM fixes and improvements Laurent Pinchart
2016-12-14  0:27 ` [PATCH v4 01/22] drm: omapdrm: fb: Limit number of planes per framebuffer to two Laurent Pinchart
2016-12-14  0:27 ` [PATCH v4 02/22] drm: omapdrm: fb: Use format information provided by the DRM core Laurent Pinchart
2016-12-14 10:07   ` Tomi Valkeinen
2016-12-14  0:27 ` [PATCH v4 03/22] drm: omapdrm: fb: Simplify objects lookup when creating framebuffer Laurent Pinchart
2016-12-14  0:27 ` [PATCH v4 04/22] drm: omapdrm: fb: Simplify mode command checks " Laurent Pinchart
2016-12-14  0:27 ` [PATCH v4 05/22] drm: omapdrm: fb: Turn framebuffer creation error messages into debug Laurent Pinchart
2016-12-14  0:27 ` [PATCH v4 06/22] drm: omapdrm: Handle FIFO underflow IRQs internally Laurent Pinchart
2016-12-14 10:22   ` Tomi Valkeinen
2016-12-14 11:48     ` Laurent Pinchart
2016-12-14 13:13       ` Tomi Valkeinen
2016-12-15  9:02       ` Tomi Valkeinen
2016-12-14  0:27 ` [PATCH v4 07/22] drm: omapdrm: Handle CRTC error IRQs directly Laurent Pinchart
2016-12-14  0:27 ` [PATCH v4 08/22] drm: omapdrm: Handle OCP error IRQ directly Laurent Pinchart
2016-12-14 10:24   ` Tomi Valkeinen
2016-12-14  0:27 ` [PATCH v4 09/22] drm: omapdrm: Replace DSS manager state check with omapdrm CRTC state Laurent Pinchart
2016-12-14 10:36   ` Tomi Valkeinen
2016-12-14  0:27 ` [PATCH v4 10/22] drm: omapdrm: Let the DRM core skip plane commit on inactive CRTCs Laurent Pinchart
2016-12-14 10:43   ` Tomi Valkeinen
2016-12-14 11:26     ` Laurent Pinchart
2016-12-14  0:27 ` [PATCH v4 11/22] drm: omapdrm: Check the CRTC software state at enable/disable time Laurent Pinchart
2016-12-14 14:54   ` Tomi Valkeinen
2016-12-14  0:27 ` [PATCH v4 12/22] drm: omapdrm: Prevent processing the same event multiple times Laurent Pinchart
2016-12-15 12:20   ` Tomi Valkeinen
2016-12-14  0:27 ` [PATCH v4 13/22] drm: omapdrm: Use a spinlock to protect the CRTC pending flag Laurent Pinchart
2016-12-14  0:27 ` [PATCH v4 14/22] drm: omapdrm: Keep vblank interrupt enabled while CRTC is active Laurent Pinchart
2016-12-15 12:52   ` Tomi Valkeinen
2016-12-15 14:51     ` Laurent Pinchart [this message]
2016-12-15 14:56       ` Tomi Valkeinen
2016-12-18  2:12   ` [PATCH v4.1 " Laurent Pinchart
2016-12-19  9:06     ` Tomi Valkeinen
2016-12-14  0:27 ` [PATCH v4 15/22] drm: omapdrm: Don't expose the omap_irq_(un)register() functions Laurent Pinchart
2016-12-15 12:56   ` Tomi Valkeinen
2016-12-14  0:27 ` [PATCH v4 16/22] drm: omapdrm: Remove unused parameter from omap_drm_irq handler Laurent Pinchart
2016-12-15 12:57   ` Tomi Valkeinen
2016-12-14  0:27 ` [PATCH v4 17/22] drm: omapdrm: Don't call DISPC power handling in IRQ wait functions Laurent Pinchart
2016-12-15 13:00   ` Tomi Valkeinen
2016-12-14  0:27 ` [PATCH v4 18/22] drm: omapdrm: Inline the pipe2vbl function Laurent Pinchart
2016-12-14 10:25   ` Tomi Valkeinen
2016-12-14  0:27 ` [PATCH v4 19/22] drm: omapdrm: Simplify IRQ wait implementation Laurent Pinchart
2016-12-16 12:24   ` Tomi Valkeinen
2016-12-14  0:27 ` [PATCH v4 20/22] drm: omapdrm: Remove global variables Laurent Pinchart
2016-12-16 12:31   ` Tomi Valkeinen
2016-12-14  0:27 ` [PATCH v4 21/22] drm: omapdrm: Use sizeof(*var) instead of sizeof(type) for structures Laurent Pinchart
2016-12-15 13:02   ` Tomi Valkeinen
2016-12-14  0:27 ` [PATCH v4 22/22] drm: omapdrm: Perform initialization/cleanup at probe/remove time Laurent Pinchart
2016-12-16 12:44   ` Tomi Valkeinen
2016-12-16 13:54     ` Laurent Pinchart
2016-12-19  9:15   ` [PATCH v4.1 " Laurent Pinchart
2016-12-19  9:25     ` Tomi Valkeinen
2016-12-14  8:48 ` [PATCH v4 00/22] OMAP DRM fixes and improvements Tomi Valkeinen
2016-12-14 11:50   ` 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=2580087.D9jCYKYxOH@avalon \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=tomi.valkeinen@ti.com \
    /path/to/YOUR_REPLY

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

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