All of lore.kernel.org
 help / color / mirror / Atom feed
From: Manasi Navare <manasi.d.navare@intel.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org,
	Kazlauskas Nicholas <Nicholas.Kazlauskas@amd.com>,
	dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v5 2/2] drm/edid: Add function to parse EDID descriptors for adaptive sync limits
Date: Tue, 10 Mar 2020 12:21:28 -0700	[thread overview]
Message-ID: <20200310192128.GA953@intel.com> (raw)
In-Reply-To: <20200310191330.GR13686@intel.com>

On Tue, Mar 10, 2020 at 09:13:30PM +0200, Ville Syrjälä wrote:
> On Tue, Mar 10, 2020 at 12:08:33PM -0700, Manasi Navare wrote:
> > Hi Ville,
> > 
> > Please find answers to your concerns below:
> > 
> > On Mon, Mar 09, 2020 at 02:39:40PM -0700, Manasi Navare wrote:
> > > Adaptive Sync is a VESA feature so add a DRM core helper to parse
> > > the EDID's detailed descritors to obtain the adaptive sync monitor range.
> > > Store this info as part fo drm_display_info so it can be used
> > > across all drivers.
> > > This part of the code is stripped out of amdgpu's function
> > > amdgpu_dm_update_freesync_caps() to make it generic and be used
> > > across all DRM drivers
> > > 
> > > v5:
> > > * Use the renamed flags
> > > v4:
> > > * Use is_display_descriptor() (Ville)
> > > * Name the monitor range flags (Ville)
> > > v3:
> > > * Remove the edid parsing restriction for just DP (Nicholas)
> > > * Use drm_for_each_detailed_block (Ville)
> > > * Make the drm_get_adaptive_sync_range function static (Harry, Jani)
> > > v2:
> > > * Change vmin and vmax to use u8 (Ville)
> > > * Dont store pixel clock since that is just a max dotclock
> > > and not related to VRR mode (Manasi)
> > > 
> > > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > Cc: Harry Wentland <harry.wentland@amd.com>
> > > Cc: Clinton A Taylor <clinton.a.taylor@intel.com>
> > > Cc: Kazlauskas Nicholas <Nicholas.Kazlauskas@amd.com>
> > > Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
> > > Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
> > > ---
> > >  drivers/gpu/drm/drm_edid.c  | 44 +++++++++++++++++++++++++++++++++++++
> > >  include/drm/drm_connector.h | 22 +++++++++++++++++++
> > >  2 files changed, 66 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > > index ad41764a4ebe..24b76ae58fdd 100644
> > > --- a/drivers/gpu/drm/drm_edid.c
> > > +++ b/drivers/gpu/drm/drm_edid.c
> > > @@ -4938,6 +4938,47 @@ static void drm_parse_cea_ext(struct drm_connector *connector,
> > >  	}
> > >  }
> > >  
> > > +static
> > > +void get_adaptive_sync_range(struct detailed_timing *timing,
> > > +			     void *info_adaptive_sync)
> > > +{
> > > +	struct drm_adaptive_sync_info *adaptive_sync = info_adaptive_sync;
> > > +	const struct detailed_non_pixel *data = &timing->data.other_data;
> > > +	const struct detailed_data_monitor_range *range = &data->data.range;
> > > +
> > > +	if (!is_display_descriptor((const u8 *)timing, EDID_DETAIL_MONITOR_RANGE))
> > > +		return;
> > > +
> > > +	/*
> > > +	 * Check for flag range limits only. If flag == 1 then
> > > +	 * no additional timing information provided.
> > > +	 * Default GTF, GTF Secondary curve and CVT are not
> > > +	 * supported
> > > +	 */
> > > +	if (range->flags != DRM_EDID_RANGE_LIMITS_ONLY_FLAG)
> > > +		return;
> > > +
> > > +	adaptive_sync->min_vfreq = range->min_vfreq;
> > > +	adaptive_sync->max_vfreq = range->max_vfreq;
> > > +}
> > > +
> > > +static
> > > +void drm_get_adaptive_sync_range(struct drm_connector *connector,
> > > +				 const struct edid *edid)
> > > +{
> > > +	struct drm_display_info *info = &connector->display_info;
> > > +
> > > +	if (!version_greater(edid, 1, 1))
> > > +		return;
> > > +
> > > +	drm_for_each_detailed_block((u8 *)edid, get_adaptive_sync_range,
> > > +				    &info->adaptive_sync);
> > 
> > Some functions like get_monitor_name also pass something like &edid_name, I dont
> > think there is any specific convention of the argument name to be passed.
> 
> Hmm. Yeah, it's a bit all over. Still I'd probably follow 
> the majority vote.
>

I feel that this name makes it more intuitive rather than adding a generic name
If you dont feel strongly about changing it, I would like to keep this as is
 
> > 
> > > +
> > > +	DRM_DEBUG_KMS("Adaptive Sync refresh rate range is %d Hz - %d Hz\n",
> > > +		      info->adaptive_sync.min_vfreq,
> > > +		      info->adaptive_sync.max_vfreq);
> > 
> > Yes I agree that this is just a monitor range and unless the dpcd ignore msa bit is set
> > and the range is atleast 10Hz apart , it might not be vrr range.
> > 
> > Would you prefer renaming this info->adaptive_sync as info->monitor_range ? Or
> > should i just print it out as Monitor range is in the dmesg but leave the info->adaptive_sync
> > naming as is?
> 
> If we want to parse it uncoditionally then I guess I'd go with the
> monitor_rage naming, and leave it up to the vrr code to know what to do
> with it.
>

Yes I plan to add a function in the driver code that checks for the msa bit and this range to be
greater than 10 to say that the sink is adaptive sync capable.

So i will just rename this struct to monitor range then?

Manasi 
> > 
> > Manasi
> > 
> > > +}
> > > +
> > >  /* A connector has no EDID information, so we've got no EDID to compute quirks from. Reset
> > >   * all of the values which would have been set from EDID
> > >   */
> > > @@ -4960,6 +5001,7 @@ drm_reset_display_info(struct drm_connector *connector)
> > >  	memset(&info->hdmi, 0, sizeof(info->hdmi));
> > >  
> > >  	info->non_desktop = 0;
> > > +	memset(&info->adaptive_sync, 0, sizeof(info->adaptive_sync));
> > >  }
> > >  
> > >  u32 drm_add_display_info(struct drm_connector *connector, const struct edid *edid)
> > > @@ -4975,6 +5017,8 @@ u32 drm_add_display_info(struct drm_connector *connector, const struct edid *edi
> > >  
> > >  	info->non_desktop = !!(quirks & EDID_QUIRK_NON_DESKTOP);
> > >  
> > > +	drm_get_adaptive_sync_range(connector, edid);
> > > +
> > >  	DRM_DEBUG_KMS("non_desktop set to %d\n", info->non_desktop);
> > >  
> > >  	if (edid->revision < 3)
> > > diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> > > index 0df7a95ca5d9..2b22c0fa42c4 100644
> > > --- a/include/drm/drm_connector.h
> > > +++ b/include/drm/drm_connector.h
> > > @@ -254,6 +254,23 @@ enum drm_panel_orientation {
> > >  	DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
> > >  };
> > >  
> > > +/**
> > > + * struct drm_adaptive_sync_info - Panel's Adaptive Sync capabilities for
> > > + * &drm_display_info
> > > + *
> > > + * This struct is used to store a Panel's Adaptive Sync capabilities
> > > + * as parsed from EDID's detailed monitor range descriptor block.
> > > + *
> > > + * @min_vfreq: This is the min supported refresh rate in Hz from
> > > + *             EDID's detailed monitor range.
> > > + * @max_vfreq: This is the max supported refresh rate in Hz from
> > > + *             EDID's detailed monitor range
> > > + */
> > > +struct drm_adaptive_sync_info {
> > > +	u8 min_vfreq;
> > > +	u8 max_vfreq;
> > > +};
> > > +
> > >  /*
> > >   * This is a consolidated colorimetry list supported by HDMI and
> > >   * DP protocol standard. The respective connectors will register
> > > @@ -473,6 +490,11 @@ struct drm_display_info {
> > >  	 * @non_desktop: Non desktop display (HMD).
> > >  	 */
> > >  	bool non_desktop;
> > > +
> > > +	/**
> > > +	 * @adaptive_sync: Adaptive Sync capabilities of the DP/eDP sink
> > > +	 */
> > > +	struct drm_adaptive_sync_info adaptive_sync;
> > >  };
> > >  
> > >  int drm_display_info_set_bus_formats(struct drm_display_info *info,
> > > -- 
> > > 2.19.1
> > > 
> 
> -- 
> Ville Syrjälä
> Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

WARNING: multiple messages have this Message-ID (diff)
From: Manasi Navare <manasi.d.navare@intel.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org,
	Harry Wentland <harry.wentland@amd.com>,
	Kazlauskas Nicholas <Nicholas.Kazlauskas@amd.com>,
	dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v5 2/2] drm/edid: Add function to parse EDID descriptors for adaptive sync limits
Date: Tue, 10 Mar 2020 12:21:28 -0700	[thread overview]
Message-ID: <20200310192128.GA953@intel.com> (raw)
In-Reply-To: <20200310191330.GR13686@intel.com>

On Tue, Mar 10, 2020 at 09:13:30PM +0200, Ville Syrjälä wrote:
> On Tue, Mar 10, 2020 at 12:08:33PM -0700, Manasi Navare wrote:
> > Hi Ville,
> > 
> > Please find answers to your concerns below:
> > 
> > On Mon, Mar 09, 2020 at 02:39:40PM -0700, Manasi Navare wrote:
> > > Adaptive Sync is a VESA feature so add a DRM core helper to parse
> > > the EDID's detailed descritors to obtain the adaptive sync monitor range.
> > > Store this info as part fo drm_display_info so it can be used
> > > across all drivers.
> > > This part of the code is stripped out of amdgpu's function
> > > amdgpu_dm_update_freesync_caps() to make it generic and be used
> > > across all DRM drivers
> > > 
> > > v5:
> > > * Use the renamed flags
> > > v4:
> > > * Use is_display_descriptor() (Ville)
> > > * Name the monitor range flags (Ville)
> > > v3:
> > > * Remove the edid parsing restriction for just DP (Nicholas)
> > > * Use drm_for_each_detailed_block (Ville)
> > > * Make the drm_get_adaptive_sync_range function static (Harry, Jani)
> > > v2:
> > > * Change vmin and vmax to use u8 (Ville)
> > > * Dont store pixel clock since that is just a max dotclock
> > > and not related to VRR mode (Manasi)
> > > 
> > > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > Cc: Harry Wentland <harry.wentland@amd.com>
> > > Cc: Clinton A Taylor <clinton.a.taylor@intel.com>
> > > Cc: Kazlauskas Nicholas <Nicholas.Kazlauskas@amd.com>
> > > Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
> > > Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
> > > ---
> > >  drivers/gpu/drm/drm_edid.c  | 44 +++++++++++++++++++++++++++++++++++++
> > >  include/drm/drm_connector.h | 22 +++++++++++++++++++
> > >  2 files changed, 66 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > > index ad41764a4ebe..24b76ae58fdd 100644
> > > --- a/drivers/gpu/drm/drm_edid.c
> > > +++ b/drivers/gpu/drm/drm_edid.c
> > > @@ -4938,6 +4938,47 @@ static void drm_parse_cea_ext(struct drm_connector *connector,
> > >  	}
> > >  }
> > >  
> > > +static
> > > +void get_adaptive_sync_range(struct detailed_timing *timing,
> > > +			     void *info_adaptive_sync)
> > > +{
> > > +	struct drm_adaptive_sync_info *adaptive_sync = info_adaptive_sync;
> > > +	const struct detailed_non_pixel *data = &timing->data.other_data;
> > > +	const struct detailed_data_monitor_range *range = &data->data.range;
> > > +
> > > +	if (!is_display_descriptor((const u8 *)timing, EDID_DETAIL_MONITOR_RANGE))
> > > +		return;
> > > +
> > > +	/*
> > > +	 * Check for flag range limits only. If flag == 1 then
> > > +	 * no additional timing information provided.
> > > +	 * Default GTF, GTF Secondary curve and CVT are not
> > > +	 * supported
> > > +	 */
> > > +	if (range->flags != DRM_EDID_RANGE_LIMITS_ONLY_FLAG)
> > > +		return;
> > > +
> > > +	adaptive_sync->min_vfreq = range->min_vfreq;
> > > +	adaptive_sync->max_vfreq = range->max_vfreq;
> > > +}
> > > +
> > > +static
> > > +void drm_get_adaptive_sync_range(struct drm_connector *connector,
> > > +				 const struct edid *edid)
> > > +{
> > > +	struct drm_display_info *info = &connector->display_info;
> > > +
> > > +	if (!version_greater(edid, 1, 1))
> > > +		return;
> > > +
> > > +	drm_for_each_detailed_block((u8 *)edid, get_adaptive_sync_range,
> > > +				    &info->adaptive_sync);
> > 
> > Some functions like get_monitor_name also pass something like &edid_name, I dont
> > think there is any specific convention of the argument name to be passed.
> 
> Hmm. Yeah, it's a bit all over. Still I'd probably follow 
> the majority vote.
>

I feel that this name makes it more intuitive rather than adding a generic name
If you dont feel strongly about changing it, I would like to keep this as is
 
> > 
> > > +
> > > +	DRM_DEBUG_KMS("Adaptive Sync refresh rate range is %d Hz - %d Hz\n",
> > > +		      info->adaptive_sync.min_vfreq,
> > > +		      info->adaptive_sync.max_vfreq);
> > 
> > Yes I agree that this is just a monitor range and unless the dpcd ignore msa bit is set
> > and the range is atleast 10Hz apart , it might not be vrr range.
> > 
> > Would you prefer renaming this info->adaptive_sync as info->monitor_range ? Or
> > should i just print it out as Monitor range is in the dmesg but leave the info->adaptive_sync
> > naming as is?
> 
> If we want to parse it uncoditionally then I guess I'd go with the
> monitor_rage naming, and leave it up to the vrr code to know what to do
> with it.
>

Yes I plan to add a function in the driver code that checks for the msa bit and this range to be
greater than 10 to say that the sink is adaptive sync capable.

So i will just rename this struct to monitor range then?

Manasi 
> > 
> > Manasi
> > 
> > > +}
> > > +
> > >  /* A connector has no EDID information, so we've got no EDID to compute quirks from. Reset
> > >   * all of the values which would have been set from EDID
> > >   */
> > > @@ -4960,6 +5001,7 @@ drm_reset_display_info(struct drm_connector *connector)
> > >  	memset(&info->hdmi, 0, sizeof(info->hdmi));
> > >  
> > >  	info->non_desktop = 0;
> > > +	memset(&info->adaptive_sync, 0, sizeof(info->adaptive_sync));
> > >  }
> > >  
> > >  u32 drm_add_display_info(struct drm_connector *connector, const struct edid *edid)
> > > @@ -4975,6 +5017,8 @@ u32 drm_add_display_info(struct drm_connector *connector, const struct edid *edi
> > >  
> > >  	info->non_desktop = !!(quirks & EDID_QUIRK_NON_DESKTOP);
> > >  
> > > +	drm_get_adaptive_sync_range(connector, edid);
> > > +
> > >  	DRM_DEBUG_KMS("non_desktop set to %d\n", info->non_desktop);
> > >  
> > >  	if (edid->revision < 3)
> > > diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> > > index 0df7a95ca5d9..2b22c0fa42c4 100644
> > > --- a/include/drm/drm_connector.h
> > > +++ b/include/drm/drm_connector.h
> > > @@ -254,6 +254,23 @@ enum drm_panel_orientation {
> > >  	DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
> > >  };
> > >  
> > > +/**
> > > + * struct drm_adaptive_sync_info - Panel's Adaptive Sync capabilities for
> > > + * &drm_display_info
> > > + *
> > > + * This struct is used to store a Panel's Adaptive Sync capabilities
> > > + * as parsed from EDID's detailed monitor range descriptor block.
> > > + *
> > > + * @min_vfreq: This is the min supported refresh rate in Hz from
> > > + *             EDID's detailed monitor range.
> > > + * @max_vfreq: This is the max supported refresh rate in Hz from
> > > + *             EDID's detailed monitor range
> > > + */
> > > +struct drm_adaptive_sync_info {
> > > +	u8 min_vfreq;
> > > +	u8 max_vfreq;
> > > +};
> > > +
> > >  /*
> > >   * This is a consolidated colorimetry list supported by HDMI and
> > >   * DP protocol standard. The respective connectors will register
> > > @@ -473,6 +490,11 @@ struct drm_display_info {
> > >  	 * @non_desktop: Non desktop display (HMD).
> > >  	 */
> > >  	bool non_desktop;
> > > +
> > > +	/**
> > > +	 * @adaptive_sync: Adaptive Sync capabilities of the DP/eDP sink
> > > +	 */
> > > +	struct drm_adaptive_sync_info adaptive_sync;
> > >  };
> > >  
> > >  int drm_display_info_set_bus_formats(struct drm_display_info *info,
> > > -- 
> > > 2.19.1
> > > 
> 
> -- 
> Ville Syrjälä
> Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2020-03-10 19:20 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-09 21:39 [PATCH v5 1/2] drm/edid: Name the detailed monitor range flags Manasi Navare
2020-03-09 21:39 ` [Intel-gfx] " Manasi Navare
2020-03-09 21:39 ` [PATCH v5 2/2] drm/edid: Add function to parse EDID descriptors for adaptive sync limits Manasi Navare
2020-03-09 21:39   ` [Intel-gfx] " Manasi Navare
2020-03-10 16:23   ` Ville Syrjälä
2020-03-10 16:23     ` [Intel-gfx] " Ville Syrjälä
2020-03-10 19:08   ` Manasi Navare
2020-03-10 19:08     ` [Intel-gfx] " Manasi Navare
2020-03-10 19:13     ` Ville Syrjälä
2020-03-10 19:13       ` [Intel-gfx] " Ville Syrjälä
2020-03-10 19:21       ` Manasi Navare [this message]
2020-03-10 19:21         ` Manasi Navare
2020-03-10 16:15 ` [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v5,1/2] drm/edid: Name the detailed monitor range flags Patchwork
2020-03-10 16:20 ` [PATCH v5 1/2] " Ville Syrjälä
2020-03-10 16:20   ` [Intel-gfx] " Ville Syrjälä
2020-03-10 19:11   ` Manasi Navare
2020-03-10 19:11     ` [Intel-gfx] " Manasi Navare
2020-03-10 20:58 ` [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v5,1/2] " 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=20200310192128.GA953@intel.com \
    --to=manasi.d.navare@intel.com \
    --cc=Nicholas.Kazlauskas@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --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.