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
next prev parent 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