All of lore.kernel.org
 help / color / mirror / Atom feed
From: Manasi Navare <manasi.d.navare@intel.com>
To: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Cc: Kazlauskas Nicholas <Nicholas.Kazlauskas@amd.com>
Subject: Re: [PATCH v5 2/2] drm/edid: Add function to parse EDID descriptors for adaptive sync limits
Date: Tue, 10 Mar 2020 12:08:33 -0700	[thread overview]
Message-ID: <20200310190833.GA717@intel.com> (raw)
In-Reply-To: <20200309213940.27965-2-manasi.d.navare@intel.com>

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.

> +
> +	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?

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
> 
_______________________________________________
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: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Cc: Harry Wentland <harry.wentland@amd.com>,
	Kazlauskas Nicholas <Nicholas.Kazlauskas@amd.com>
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:08:33 -0700	[thread overview]
Message-ID: <20200310190833.GA717@intel.com> (raw)
In-Reply-To: <20200309213940.27965-2-manasi.d.navare@intel.com>

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.

> +
> +	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?

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
> 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  parent reply	other threads:[~2020-03-10 19:07 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 [this message]
2020-03-10 19:08     ` 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
2020-03-10 19:21         ` [Intel-gfx] " 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=20200310190833.GA717@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 \
    /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.