All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Kannan, Vandana" <vandana.kannan@intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: "intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH 4/8] drm/i915: DRRS calls based on frontbuffer
Date: Mon, 15 Dec 2014 19:45:13 +0530	[thread overview]
Message-ID: <548EECF1.6020602@intel.com> (raw)
In-Reply-To: <20141215095705.GN27182@phenom.ffwll.local>



On 15-Dec-14 3:27 PM, Daniel Vetter wrote:
> On Thu, Dec 11, 2014 at 02:22:53AM +0530, Vandana Kannan wrote:
>> Calls have been added to invalidate/flush DRRS whenever invalidate/flush is
>> called as part of frontbuffer tracking.
>> Apart from calls as a result of GEM tracking to fb invalidate/flush, a
>> call has been added to invalidate fb obj from crtc_page_flip as well. This
>> is to track busyness through flip calls.
>
> That shouldn't be required really. Or maybe I misunderstand what you mean
> here ...
>
Last month when I was implementing this, DRRS worked as expected only 
when this call was made from crtc_page_flip. I checked the recent code 
today and as you mentioned above, this call isn't required.
I can remove this call from this patch..
Having said that, sometime back I observed that Android used 
crtc_page_flip and its possible that DRRS would break in that scenario 
without this call to invalidate..
- Vandana

>> The call to fb_obj_invalidate (in flip) is placed before queuing flip for this
>> obj.
>>
>> drrs_invalidate() and drrs_flush() check for drrs.dp which would be NULL if
>> it was setup in drrs_enable(). This covers for the condition when DRRS is
>> not supported.
>>
>> Signed-off-by: Vandana Kannan <vandana.kannan@intel.com>
>> ---
>>   drivers/gpu/drm/i915/intel_display.c     |  8 +++--
>>   drivers/gpu/drm/i915/intel_dp.c          | 51 ++++++++++++++++++++++++++++++++
>>   drivers/gpu/drm/i915/intel_drv.h         |  3 ++
>>   drivers/gpu/drm/i915/intel_frontbuffer.c |  2 ++
>>   4 files changed, 61 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
>> index a9bdc12..a4a565c 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -9717,6 +9717,11 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
>>   	if (ret)
>>   		goto cleanup_pending;
>>
>> +	i915_gem_track_fb(work->old_fb_obj, obj,
>> +			  INTEL_FRONTBUFFER_PRIMARY(pipe));
>> +
>> +	intel_fb_obj_invalidate(obj, ring);
>> +
>>   	work->gtt_offset =
>>   		i915_gem_obj_ggtt_offset(obj) + intel_crtc->dspaddr_offset;
>>
>> @@ -9741,9 +9746,6 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
>>   	work->flip_queued_vblank = drm_vblank_count(dev, intel_crtc->pipe);
>>   	work->enable_stall_check = true;
>>
>> -	i915_gem_track_fb(work->old_fb_obj, obj,
>> -			  INTEL_FRONTBUFFER_PRIMARY(pipe));
>> -
>>   	intel_disable_fbc(dev);
>>   	intel_frontbuffer_flip_prepare(dev, INTEL_FRONTBUFFER_PRIMARY(pipe));
>>   	mutex_unlock(&dev->struct_mutex);
>
> This hunk here looks spurious. Or is it relate to what you mention in the
> commit message? Please explain more in-depth.
>
>> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
>> index 7098470..bc17900 100644
>> --- a/drivers/gpu/drm/i915/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/intel_dp.c
>> @@ -4902,6 +4902,57 @@ unlock:
>>   	mutex_unlock(&dev_priv->drrs.mutex);
>>   }
>>
>> +void intel_edp_drrs_invalidate(struct drm_device *dev,
>> +		unsigned frontbuffer_bits)
>> +{
>> +	struct drm_i915_private *dev_priv = dev->dev_private;
>> +	struct drm_crtc *crtc;
>> +	enum pipe pipe;
>> +
>> +	if (!dev_priv->drrs.dp)
>> +		return;
>> +
>> +	mutex_lock(&dev_priv->drrs.mutex);
>> +	crtc = dp_to_dig_port(dev_priv->drrs.dp)->base.base.crtc;
>> +	pipe = to_intel_crtc(crtc)->pipe;
>> +
>> +	if (dev_priv->drrs.refresh_rate_type == DRRS_LOW_RR) {
>> +		cancel_delayed_work_sync(&dev_priv->drrs.work);
>> +		intel_dp_set_drrs_state(dev_priv->dev,
>> +				dev_priv->drrs.dp->attached_connector->panel.
>> +				fixed_mode->vrefresh);
>> +	}
>> +
>> +	frontbuffer_bits &= INTEL_FRONTBUFFER_ALL_MASK(pipe);
>> +
>> +	dev_priv->drrs.busy_frontbuffer_bits |= frontbuffer_bits;
>> +	mutex_unlock(&dev_priv->drrs.mutex);
>> +}
>> +
>> +void intel_edp_drrs_flush(struct drm_device *dev,
>> +		unsigned frontbuffer_bits)
>> +{
>> +	struct drm_i915_private *dev_priv = dev->dev_private;
>> +	struct drm_crtc *crtc;
>> +	enum pipe pipe;
>> +
>> +	if (!dev_priv->drrs.dp)
>> +		return;
>> +
>> +	mutex_lock(&dev_priv->drrs.mutex);
>> +	crtc = dp_to_dig_port(dev_priv->drrs.dp)->base.base.crtc;
>> +	pipe = to_intel_crtc(crtc)->pipe;
>> +	dev_priv->drrs.busy_frontbuffer_bits &= ~frontbuffer_bits;
>> +
>> +	cancel_delayed_work_sync(&dev_priv->drrs.work);
>> +
>> +	if (dev_priv->drrs.refresh_rate_type != DRRS_LOW_RR &&
>> +			!dev_priv->drrs.busy_frontbuffer_bits)
>> +		schedule_delayed_work(&dev_priv->drrs.work,
>> +				msecs_to_jiffies(1000));
>
> With mod_delayed_work you can avoid the cancel_work. Also sync will
> probably deadlock.
> -Daniel
>
>> +	mutex_unlock(&dev_priv->drrs.mutex);
>> +}
>> +
>>   static struct drm_display_mode *
>>   intel_dp_drrs_init(struct intel_connector *intel_connector,
>>   		struct drm_display_mode *fixed_mode)
>> diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
>> index 1c3c25a..763c097 100644
>> --- a/drivers/gpu/drm/i915/intel_drv.h
>> +++ b/drivers/gpu/drm/i915/intel_drv.h
>> @@ -1004,6 +1004,9 @@ int intel_update_plane(struct drm_plane *plane, struct drm_crtc *crtc,
>>   int intel_disable_plane(struct drm_plane *plane);
>>   void intel_edp_drrs_enable(struct intel_dp *intel_dp);
>>   void intel_edp_drrs_disable(struct intel_dp *intel_dp);
>> +void intel_edp_drrs_invalidate(struct drm_device *dev,
>> +		unsigned frontbuffer_bits);
>> +void intel_edp_drrs_flush(struct drm_device *dev, unsigned frontbuffer_bits);
>>
>>   /* intel_dp_mst.c */
>>   int intel_dp_mst_encoder_init(struct intel_digital_port *intel_dig_port, int conn_id);
>> diff --git a/drivers/gpu/drm/i915/intel_frontbuffer.c b/drivers/gpu/drm/i915/intel_frontbuffer.c
>> index 79f6d72..73cb6e0 100644
>> --- a/drivers/gpu/drm/i915/intel_frontbuffer.c
>> +++ b/drivers/gpu/drm/i915/intel_frontbuffer.c
>> @@ -157,6 +157,7 @@ void intel_fb_obj_invalidate(struct drm_i915_gem_object *obj,
>>   	intel_mark_fb_busy(dev, obj->frontbuffer_bits, ring);
>>
>>   	intel_psr_invalidate(dev, obj->frontbuffer_bits);
>> +	intel_edp_drrs_invalidate(dev, obj->frontbuffer_bits);
>>   }
>>
>>   /**
>> @@ -182,6 +183,7 @@ void intel_frontbuffer_flush(struct drm_device *dev,
>>
>>   	intel_mark_fb_busy(dev, frontbuffer_bits, NULL);
>>
>> +	intel_edp_drrs_flush(dev, frontbuffer_bits);
>>   	intel_psr_flush(dev, frontbuffer_bits);
>>
>>   	/*
>> --
>> 2.0.1
>>
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-10 20:52 [PATCH 0/8] eDP DRRS based on frontbuffer tracking Vandana Kannan
2014-12-10 20:52 ` [PATCH 1/8] drm/i915: Modifying structures related to DRRS Vandana Kannan
2014-12-10 20:52 ` [PATCH 2/8] drm/i915: Initialize DRRS delayed work Vandana Kannan
2014-12-10 20:52 ` [PATCH 3/8] drm/i915: Enable/disable DRRS Vandana Kannan
2014-12-10 20:52 ` [PATCH 4/8] drm/i915: DRRS calls based on frontbuffer Vandana Kannan
2014-12-15  9:57   ` Daniel Vetter
2014-12-15 14:15     ` Kannan, Vandana [this message]
2014-12-15 14:24       ` Daniel Vetter
2014-12-10 20:52 ` [PATCH 5/8] drm/i915/bdw: Add support for DRRS to switch RR Vandana Kannan
2014-12-10 20:52 ` [PATCH 6/8] drm/i915: Support for RR switching on VLV Vandana Kannan
2014-12-10 20:52 ` [PATCH 7/8] drm/i915: Enable eDP DRRS for CHV Vandana Kannan
2014-12-10 20:52 ` [PATCH 8/8] drm/i915: Add drrs_interval module parameter Vandana Kannan
2014-12-11  6:10   ` shuang.he
2014-12-15  9:47   ` Daniel Vetter
2014-12-15 10:55     ` Kannan, Vandana
2014-12-15 14:16       ` Daniel Vetter
2014-12-15 14:26         ` Kannan, Vandana
2014-12-15 14:38           ` Daniel Vetter
2014-12-15 10:00 ` [PATCH 0/8] eDP DRRS based on frontbuffer tracking Daniel Vetter
2014-12-15 14:00   ` Kannan, Vandana

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=548EECF1.6020602@intel.com \
    --to=vandana.kannan@intel.com \
    --cc=daniel@ffwll.ch \
    --cc=intel-gfx@lists.freedesktop.org \
    /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.