All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Modem, Bhanuprakash" <bhanuprakash.modem@intel.com>
To: "Navare, Manasi" <manasi.d.navare@intel.com>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [RFC V3 2/2] drm/i915/vrr: Set drm crtc vrr_enabled property
Date: Wed, 1 Jun 2022 16:01:35 +0530	[thread overview]
Message-ID: <d5e08967-6bdb-3f9c-b014-7f8e069c2aa4@intel.com> (raw)
In-Reply-To: <20220531171451.GB257110@mdnavare-mobl1.jf.intel.com>

On Tue-31-05-2022 10:44 pm, Navare, Manasi wrote:
> On Tue, May 17, 2022 at 12:56:36PM +0530, Bhanuprakash Modem wrote:
>> This function sets the vrr_enabled property for crtc based
>> on the platform support and the request from userspace.
>>
>> V2: Check for platform support before updating the prop.
>> V3: Don't attach vrr_enabled prop, as it is alreay attached.
>>
>> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
>> Cc: Manasi Navare <manasi.d.navare@intel.com>
>> Signed-off-by: Bhanuprakash Modem <bhanuprakash.modem@intel.com>
>> ---
>>   drivers/gpu/drm/i915/display/intel_vrr.c | 8 ++++++++
>>   1 file changed, 8 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c b/drivers/gpu/drm/i915/display/intel_vrr.c
>> index 396f2f994fa0..7263b35550de 100644
>> --- a/drivers/gpu/drm/i915/display/intel_vrr.c
>> +++ b/drivers/gpu/drm/i915/display/intel_vrr.c
>> @@ -160,6 +160,10 @@ void intel_vrr_enable(struct intel_encoder *encoder,
>>   	enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
>>   	u32 trans_vrr_ctl;
>>   
>> +	if (HAS_VRR(dev_priv))
>> +		drm_mode_crtc_set_vrr_enabled_property(crtc_state->uapi.crtc,
>> +						       crtc_state->vrr.enable);
> 
> But here if userspace has accidently set the CRTC vrr enabled prop to
> true without cheking VRR capabile prop, this will be true and here the
> driver will still not
> reset it. If that is the purpose of adding this then we should infact
> set this to false if !HAS_VRR

Yes, my intention is same as you mentioned. But this looks correct to 
me, because:

1) HAS_VRR() is a check to make sure that the driver supports VRR. If 
there is no VRR support on the driver, then there is no point to 
set/clear this prop.

2) crtc_state->vrr.enable is true If vrr_capable is set to true, else false.

So we can interpret above check as below

enable_VRR() {
	IF Driver supports VRR:
		IF VRR_CAPABLE:
			Set VRR_ENABLED;
		ELSE:
			Clear VRR_ENABLED;
	ELSE:
		Do nothing;
}

- Bhanu

> 
> Manasi
> 
>> +
>>   	if (!crtc_state->vrr.enable)
>>   		return;
>>   
>> @@ -211,6 +215,10 @@ void intel_vrr_disable(const struct intel_crtc_state *old_crtc_state)
>>   	struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>>   	enum transcoder cpu_transcoder = old_crtc_state->cpu_transcoder;
>>   
>> +	if (HAS_VRR(dev_priv))
>> +		drm_mode_crtc_set_vrr_enabled_property(old_crtc_state->uapi.crtc,
>> +						       false);
>> +
>>   	if (!old_crtc_state->vrr.enable)
>>   		return;
>>   
>> -- 
>> 2.35.1
>>


WARNING: multiple messages have this Message-ID (diff)
From: "Modem, Bhanuprakash" <bhanuprakash.modem@intel.com>
To: "Navare, Manasi" <manasi.d.navare@intel.com>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [RFC V3 2/2] drm/i915/vrr: Set drm crtc vrr_enabled property
Date: Wed, 1 Jun 2022 16:01:35 +0530	[thread overview]
Message-ID: <d5e08967-6bdb-3f9c-b014-7f8e069c2aa4@intel.com> (raw)
In-Reply-To: <20220531171451.GB257110@mdnavare-mobl1.jf.intel.com>

On Tue-31-05-2022 10:44 pm, Navare, Manasi wrote:
> On Tue, May 17, 2022 at 12:56:36PM +0530, Bhanuprakash Modem wrote:
>> This function sets the vrr_enabled property for crtc based
>> on the platform support and the request from userspace.
>>
>> V2: Check for platform support before updating the prop.
>> V3: Don't attach vrr_enabled prop, as it is alreay attached.
>>
>> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
>> Cc: Manasi Navare <manasi.d.navare@intel.com>
>> Signed-off-by: Bhanuprakash Modem <bhanuprakash.modem@intel.com>
>> ---
>>   drivers/gpu/drm/i915/display/intel_vrr.c | 8 ++++++++
>>   1 file changed, 8 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c b/drivers/gpu/drm/i915/display/intel_vrr.c
>> index 396f2f994fa0..7263b35550de 100644
>> --- a/drivers/gpu/drm/i915/display/intel_vrr.c
>> +++ b/drivers/gpu/drm/i915/display/intel_vrr.c
>> @@ -160,6 +160,10 @@ void intel_vrr_enable(struct intel_encoder *encoder,
>>   	enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
>>   	u32 trans_vrr_ctl;
>>   
>> +	if (HAS_VRR(dev_priv))
>> +		drm_mode_crtc_set_vrr_enabled_property(crtc_state->uapi.crtc,
>> +						       crtc_state->vrr.enable);
> 
> But here if userspace has accidently set the CRTC vrr enabled prop to
> true without cheking VRR capabile prop, this will be true and here the
> driver will still not
> reset it. If that is the purpose of adding this then we should infact
> set this to false if !HAS_VRR

Yes, my intention is same as you mentioned. But this looks correct to 
me, because:

1) HAS_VRR() is a check to make sure that the driver supports VRR. If 
there is no VRR support on the driver, then there is no point to 
set/clear this prop.

2) crtc_state->vrr.enable is true If vrr_capable is set to true, else false.

So we can interpret above check as below

enable_VRR() {
	IF Driver supports VRR:
		IF VRR_CAPABLE:
			Set VRR_ENABLED;
		ELSE:
			Clear VRR_ENABLED;
	ELSE:
		Do nothing;
}

- Bhanu

> 
> Manasi
> 
>> +
>>   	if (!crtc_state->vrr.enable)
>>   		return;
>>   
>> @@ -211,6 +215,10 @@ void intel_vrr_disable(const struct intel_crtc_state *old_crtc_state)
>>   	struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>>   	enum transcoder cpu_transcoder = old_crtc_state->cpu_transcoder;
>>   
>> +	if (HAS_VRR(dev_priv))
>> +		drm_mode_crtc_set_vrr_enabled_property(old_crtc_state->uapi.crtc,
>> +						       false);
>> +
>>   	if (!old_crtc_state->vrr.enable)
>>   		return;
>>   
>> -- 
>> 2.35.1
>>


  reply	other threads:[~2022-06-01 10:31 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-17  7:26 [RFC V3 0/2] Attach and Set vrr_enabled property Bhanuprakash Modem
2022-05-17  7:26 ` [Intel-gfx] " Bhanuprakash Modem
2022-05-17  7:26 ` [RFC V3 1/2] drm/vrr: Attach vrr_enabled property to the drm crtc Bhanuprakash Modem
2022-05-17  7:26   ` [Intel-gfx] " Bhanuprakash Modem
2022-05-31 17:12   ` Navare, Manasi
2022-05-31 17:12     ` [Intel-gfx] " Navare, Manasi
2022-06-01 10:31     ` Modem, Bhanuprakash
2022-06-01 10:31       ` [Intel-gfx] " Modem, Bhanuprakash
2022-05-17  7:26 ` [RFC V3 2/2] drm/i915/vrr: Set drm crtc vrr_enabled property Bhanuprakash Modem
2022-05-17  7:26   ` [Intel-gfx] " Bhanuprakash Modem
2022-05-31 17:14   ` Navare, Manasi
2022-05-31 17:14     ` [Intel-gfx] " Navare, Manasi
2022-06-01 10:31     ` Modem, Bhanuprakash [this message]
2022-06-01 10:31       ` Modem, Bhanuprakash
2022-05-17  8:17 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Attach and Set vrr_enabled property (rev3) Patchwork
2022-05-17  8:17 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-05-17  8:25 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2022-05-31  9:00 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Attach and Set vrr_enabled property (rev4) Patchwork
2022-05-31  9:00 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-05-31  9:22 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2022-05-31 13:56 ` [RFC V3 0/2] Attach and Set vrr_enabled property Daniel Vetter
2022-05-31 13:56   ` [Intel-gfx] " Daniel Vetter
2022-06-01 10:31   ` Modem, Bhanuprakash
2022-06-01 10:31     ` [Intel-gfx] " Modem, Bhanuprakash

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=d5e08967-6bdb-3f9c-b014-7f8e069c2aa4@intel.com \
    --to=bhanuprakash.modem@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=manasi.d.navare@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.