public inbox for intel-gfx@lists.freedesktop.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox