From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: "Michel Dänzer" <michel@daenzer.net>,
dri-devel@lists.freedesktop.org,
"Laurent Pinchart" <laurent.pinchart@ideasonboard.com>,
"Dave Airlie" <airlied@redhat.com>,
intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm: Make the decision to keep vblank irq enabled earlier
Date: Thu, 23 Mar 2017 15:26:42 +0200 [thread overview]
Message-ID: <20170323132642.GS31595@intel.com> (raw)
In-Reply-To: <20170323075106.7494-1-chris@chris-wilson.co.uk>
On Thu, Mar 23, 2017 at 07:51:06AM +0000, Chris Wilson wrote:
> We want to provide the vblank irq shadow for pageflip events as well as
> vblank queries. Such events are completed within the vblank interrupt
> handler, and so the current check for disabling the irq will disable it
> from with the same interrupt as the last pageflip event. If we move the
> decision on whether to disable the irq (based on there no being no
> remaining vblank events, i.e. vblank->refcount == 0) to before we signal
> the events, we will only disable the irq on the interrupt after the last
> event was signaled. In the normal course of events, this will keep the
> vblank irq enabled for the entire flip sequence whereas before it would
> flip-flop around every interrupt.
>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Michel Dänzer <michel@daenzer.net>
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Cc: Dave Airlie <airlied@redhat.com>,
> Cc: Mario Kleiner <mario.kleiner.de@gmail.com>
> ---
> drivers/gpu/drm/drm_irq.c | 18 +++++++++++-------
> 1 file changed, 11 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 5b77057e91ca..1d6bcee3708f 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -1741,6 +1741,7 @@ bool drm_handle_vblank(struct drm_device *dev, unsigned int pipe)
> {
> struct drm_vblank_crtc *vblank = &dev->vblank[pipe];
> unsigned long irqflags;
> + bool disable_irq;
>
> if (WARN_ON_ONCE(!dev->num_crtcs))
> return false;
> @@ -1768,16 +1769,19 @@ bool drm_handle_vblank(struct drm_device *dev, unsigned int pipe)
> spin_unlock(&dev->vblank_time_lock);
>
> wake_up(&vblank->queue);
> - drm_handle_vblank_events(dev, pipe);
>
> /* With instant-off, we defer disabling the interrupt until after
> - * we finish processing the following vblank. The disable has to
> - * be last (after drm_handle_vblank_events) so that the timestamp
> - * is always accurate.
> + * we finish processing the following vblank after all events have
> + * been signaled. The disable has to be last (after
> + * drm_handle_vblank_events) so that the timestamp is always accurate.
We wouldn't actually do the disable as long there's a reference still
held, so the timestamp should be fine in that case. And if there aren't
any references the timestamp shouldn't matter... I think. But it's
probably more clear to keep to the order you propose here anyway.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Oh, and now that I think about this stuff again, I start to wonder why
I made the disable actually update the seq/ts. If the interrupt is
currently enabled the seq/ts should be reasonably uptodate already
when we do disable the interrupt. Perhaps I was only thinking about
drm_vblank_off() when I made that change, or I decided that I didn't
want two different disable codepaths. Anyways, just an idea that
we might be able to make the vblank irq disable a little cheaper.
> */
> - if (dev->vblank_disable_immediate &&
> - drm_vblank_offdelay > 0 &&
> - !atomic_read(&vblank->refcount))
> + disable_irq = (dev->vblank_disable_immediate &&
> + drm_vblank_offdelay > 0 &&
> + !atomic_read(&vblank->refcount));
> +
> + drm_handle_vblank_events(dev, pipe);
> +
> + if (disable_irq)
> vblank_disable_fn((unsigned long)vblank);
>
> spin_unlock_irqrestore(&dev->event_lock, irqflags);
> --
> 2.11.0
--
Ville Syrjälä
Intel OTC
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2017-03-23 13:26 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-15 20:40 [PATCH 1/3] drm: Defer disabling the vblank IRQ until the next interrupt (for instant-off) Chris Wilson
2017-03-15 20:40 ` [PATCH 2/3] drm: Skip the waitqueue setup for vblank queries Chris Wilson
2017-03-16 9:23 ` Daniel Vetter
2017-03-15 20:40 ` [PATCH 3/3] drm: Peek at the current counter/timestamp " Chris Wilson
2017-03-15 21:06 ` Ville Syrjälä
2017-03-15 21:44 ` Chris Wilson
2017-03-15 21:00 ` [PATCH 1/3] drm: Defer disabling the vblank IRQ until the next interrupt (for instant-off) Ville Syrjälä
2017-03-22 15:06 ` Mario Kleiner
2017-03-22 20:02 ` Ville Syrjälä
2017-03-23 7:51 ` [PATCH] drm: Make the decision to keep vblank irq enabled earlier Chris Wilson
2017-03-23 8:06 ` Chris Wilson
2017-03-23 13:26 ` Ville Syrjälä [this message]
2017-03-24 3:16 ` Mario Kleiner
2017-03-24 17:28 ` Chris Wilson
2017-03-24 17:30 ` [PATCH v2] " Chris Wilson
2017-03-29 11:31 ` Ville Syrjälä
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=20170323132642.GS31595@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=airlied@redhat.com \
--cc=chris@chris-wilson.co.uk \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=laurent.pinchart@ideasonboard.com \
--cc=michel@daenzer.net \
/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;
as well as URLs for NNTP newsgroup(s).