All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mario Kleiner <mario.kleiner.de@gmail.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>,
	"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: Fri, 24 Mar 2017 04:16:28 +0100	[thread overview]
Message-ID: <4098543f-16e1-ca44-cdf2-157bdb66b188@gmail.com> (raw)
In-Reply-To: <20170323132642.GS31595@intel.com>

On 03/23/2017 02:26 PM, Ville Syrjälä wrote:
> 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>
>

Looks good to me. As a further optimization, i think we could move the 
vblank_disable_fn() call outside/below the spin_unlock_irqrestore for 
event_lock, as vblank_disable_fn() doesn't need any locks held at call 
time, so slightly reduce event_lock hold time. Don't know if it is worth it.

In any case

Reviewed-by: Mario Kleiner <mario.kleiner.de@gmail.com>

thanks,
-mario

> 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
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2017-03-24  3:16 UTC|newest]

Thread overview: 19+ 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ä
2017-03-24  3:16           ` Mario Kleiner [this message]
2017-03-24 17:28             ` Chris Wilson
2017-03-24 17:30             ` [PATCH v2] " Chris Wilson
2017-03-29 11:31               ` Ville Syrjälä
2017-03-15 21:21 ` ✓ Fi.CI.BAT: success for series starting with [1/3] drm: Defer disabling the vblank IRQ until the next interrupt (for instant-off) Patchwork
2017-03-23 11:22 ` ✓ Fi.CI.BAT: success for series starting with drm: Make the decision to keep vblank irq enabled earlier (rev2) Patchwork
2017-03-24 17:52 ` ✓ Fi.CI.BAT: success for series starting with [v2] drm: Make the decision to keep vblank irq enabled earlier (rev3) Patchwork

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=4098543f-16e1-ca44-cdf2-157bdb66b188@gmail.com \
    --to=mario.kleiner.de@gmail.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 \
    --cc=ville.syrjala@linux.intel.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 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.