All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
To: "Pandiyan, Dhinakaran" <dhinakaran.pandiyan@intel.com>
Cc: "intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"bberg@redhat.com" <bberg@redhat.com>,
	"Vivi, Rodrigo" <rodrigo.vivi@intel.com>
Subject: Re: [PATCH] drm/i915: Handle changing enable_psr parameter at runtime better
Date: Thu, 8 Mar 2018 08:07:54 +0100	[thread overview]
Message-ID: <fab412f6-47d1-7a3a-b07f-efcfdb1240a2@linux.intel.com> (raw)
In-Reply-To: <1520462797.20396.49.camel@dk-H97M-D3H>

Op 07-03-18 om 23:22 schreef Pandiyan, Dhinakaran:
> On Wed, 2018-03-07 at 17:39 +0100, Maarten Lankhorst wrote:
>> Similar to enable_fbc, enable_psr was ignored at runtime if it was
>> changed. The easiest fix is to pretend enable_psr is ignored at
>> configure time, and never activate it for !enable_psr, so both cases
>> are handled without modesets.
> What about cases where psr_flush() is not called and consequently the
> module parameter is not checked? With HW tracking, PSR is
> enabled/disabled during modeset and the hardware is expected to exit and
> activate PSR without driver intervention.
It looks like intel_frontbuffer_flush always calls intel_psr_flush,
so we at least get a PSR toggle after every atomic commit?

~Maarten

>> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>> Tested-by: Benjamin Berg <bberg@redhat.com>
>> Cc: Benjamin Berg <bberg@redhat.com>
>> ---
>>  drivers/gpu/drm/i915/intel_psr.c | 19 ++++++++++---------
>>  1 file changed, 10 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
>> index 23175c5c4a50..ac3ce7a1c2a7 100644
>> --- a/drivers/gpu/drm/i915/intel_psr.c
>> +++ b/drivers/gpu/drm/i915/intel_psr.c
>> @@ -502,11 +502,6 @@ void intel_psr_compute_config(struct intel_dp *intel_dp,
>>  	if (!CAN_PSR(dev_priv))
>>  		return;
>>  
>> -	if (!i915_modparams.enable_psr) {
>> -		DRM_DEBUG_KMS("PSR disable by flag\n");
>> -		return;
>> -	}
>> -
>>  	/*
>>  	 * HSW spec explicitly says PSR is tied to port A.
>>  	 * BDW+ platforms with DDI implementation of PSR have different
>> @@ -559,7 +554,10 @@ void intel_psr_compute_config(struct intel_dp *intel_dp,
>>  
>>  	crtc_state->has_psr = true;
>>  	crtc_state->has_psr2 = intel_psr2_config_valid(intel_dp, crtc_state);
>> -	DRM_DEBUG_KMS("Enabling PSR%s\n", crtc_state->has_psr2 ? "2" : "");
>> +	if (i915_modparams.enable_psr)
>> +		DRM_DEBUG_KMS("Enabling PSR%s\n", crtc_state->has_psr2 ? "2" : "");
>> +	else
>> +		DRM_DEBUG_KMS("PSR disable by flag\n");
>>  }
>>  
>>  static void intel_psr_activate(struct intel_dp *intel_dp)
>> @@ -652,7 +650,9 @@ void intel_psr_enable(struct intel_dp *intel_dp,
>>  	dev_priv->psr.enable_source(intel_dp, crtc_state);
>>  	dev_priv->psr.enabled = intel_dp;
>>  
>> -	if (INTEL_GEN(dev_priv) >= 9) {
>> +	if (!i915_modparams.enable_psr) {
>> +		DRM_DEBUG_KMS("PSR disable by flag\n");
>> +	} else if (INTEL_GEN(dev_priv) >= 9) {
>>  		intel_psr_activate(intel_dp);
>>  	} else {
>>  		/*
>> @@ -843,7 +843,7 @@ static void intel_psr_work(struct work_struct *work)
>>  	 * recheck. Since psr_flush first clears this and then reschedules we
>>  	 * won't ever miss a flush when bailing out here.
>>  	 */
>> -	if (dev_priv->psr.busy_frontbuffer_bits)
>> +	if (dev_priv->psr.busy_frontbuffer_bits || !i915_modparams.enable_psr)
>>  		goto unlock;
>>  
>>  	intel_psr_activate(intel_dp);
>> @@ -1015,7 +1015,8 @@ void intel_psr_flush(struct drm_i915_private *dev_priv,
>>  		return;
>>  
>>  	mutex_lock(&dev_priv->psr.lock);
>> -	if (!dev_priv->psr.enabled) {
>> +	if (!dev_priv->psr.enabled || !i915_modparams.enable_psr) {
>> +		intel_psr_exit(dev_priv);
>>  		mutex_unlock(&dev_priv->psr.lock);
>>  		return;
>>  	}


_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2018-03-08  7:07 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-07 16:39 [PATCH] drm/i915: Handle changing enable_psr parameter at runtime better Maarten Lankhorst
2018-03-07 16:59 ` ✓ Fi.CI.BAT: success for " Patchwork
2018-03-07 19:02 ` ✓ Fi.CI.IGT: " Patchwork
2018-03-07 22:22 ` [PATCH] " Pandiyan, Dhinakaran
2018-03-08  7:07   ` Maarten Lankhorst [this message]
2018-03-08 17:43     ` Pandiyan, Dhinakaran
2018-03-08 17:52       ` Maarten Lankhorst
2018-03-08 18:07         ` Pandiyan, Dhinakaran
2018-03-08 19:08           ` Rodrigo Vivi

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=fab412f6-47d1-7a3a-b07f-efcfdb1240a2@linux.intel.com \
    --to=maarten.lankhorst@linux.intel.com \
    --cc=bberg@redhat.com \
    --cc=dhinakaran.pandiyan@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=rodrigo.vivi@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.