[Intel-gfx] [PATCH] drm/dp: Add function to parse EDID descriptors for adaptive sync limits
Ville Syrjälä
ville.syrjala at linux.intel.com
Thu Oct 24 14:20:32 UTC 2019
On Thu, Oct 24, 2019 at 03:54:41PM +0200, Thierry Reding wrote:
> On Thu, Oct 24, 2019 at 02:34:00PM +0300, Ville Syrjälä wrote:
> > On Thu, Oct 24, 2019 at 12:31:06PM +0200, Thierry Reding wrote:
> > > On Wed, Oct 23, 2019 at 05:00:41PM -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
> > > >
> > > > Cc: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > > > Cc: Harry Wentland <harry.wentland at amd.com>
> > > > Cc: Clinton A Taylor <clinton.a.taylor at intel.com>
> > > > Signed-off-by: Manasi Navare <manasi.d.navare at intel.com>
> > > > ---
> > > > drivers/gpu/drm/drm_edid.c | 49 +++++++++++++++++++++++++++++++++++++
> > > > include/drm/drm_connector.h | 25 +++++++++++++++++++
> > > > include/drm/drm_edid.h | 2 ++
> > > > 3 files changed, 76 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > > > index 474ac04d5600..97dd1200773e 100644
> > > > --- a/drivers/gpu/drm/drm_edid.c
> > > > +++ b/drivers/gpu/drm/drm_edid.c
> > > > @@ -4707,6 +4707,52 @@ static void drm_parse_cea_ext(struct drm_connector *connector,
> > > > }
> > > > }
> > > >
> > > > +void drm_get_adaptive_sync_limits(struct drm_connector *connector,
> > > > + const struct edid *edid)
> > > > +{
> > > > + struct drm_display_info *info = &connector->display_info;
> > > > + const struct detailed_timing *timing;
> > > > + const struct detailed_non_pixel *data;
> > > > + const struct detailed_data_monitor_range *range;
> > > > + int i;
> > >
> > > This can be unsigned int.
> >
> > Please no. A loop iterator called 'i' should always be a normal signed int.
>
> What? Where's that rule written down? In my experience it's always
> better to use as restrictive a type as possible. It's really annoying
> when GCC suddenly starts complaining about comparison between signed and
> unsigned. So if a variable can never contain a signed value, why risk
> the ambiguity? The value goes from 0 to 4, the sign bit is useless.
Dunno if it's really written down anywhere. It's just something
experience has taught. IIRC there's also a rant from Linus about this
somewhere. Hm, can't find that one right now, but Andrew Morton also
seems to agree: https://lwn.net/Articles/309279/
Ah, here is one Linus rant about unsigned array indexes:
https://yarchive.net/comp/linux/gcc.html
My opinion: unsigned is an very *dangerous* keyword in C that demands
your respect. You should never use it without thinking first what the
ramifications are. You always have to have the promotion rules clear
in you mind when you do any kind of arithmetic with >= unsigned int
type. And common idioms such as 'int i' should be respected so as to
not cause unexpected hair loss to other developers when they decide
to make the loop iterate backwards.
>
> > > > + /*
> > > > + * Restrict Adaptive Sync only for dp and edp
> > > > + */
> > > > + if (connector->connector_type != DRM_MODE_CONNECTOR_DisplayPort &&
> > > > + connector->connector_type != DRM_MODE_CONNECTOR_eDP)
> > > > + return;
> > > > +
> > > > + if (edid->version <= 1 && !(edid->version == 1 && edid->revision > 1))
> > > > + return;
> > > > +
> > > > + for (i = 0; i < 4; i++) {
> > > > + timing = &edid->detailed_timings[i];
> > > > + data = &timing->data.other_data;
> > > > + range = &data->data.range;
> > > > + /*
> > > > + * Check if monitor has continuous frequency mode
> > > > + */
> > > > + if (data->type != EDID_DETAIL_MONITOR_RANGE)
> > > > + continue;
> > > > + /*
> > > > + * 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 != 1)
> > > > + continue;
> > > > +
> > > > + info->adaptive_sync.min_vfreq = range->min_vfreq;
> > > > + info->adaptive_sync.max_vfreq = range->max_vfreq;
> > > > + info->adaptive_sync.pixel_clock_mhz =
> > > > + range->pixel_clock_mhz * 10;
> > > > + break;
> > > > + }
> > > > +}
> > > > +EXPORT_SYMBOL(drm_get_adaptive_sync_limits);
> > > > +
> > > > /* 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
> > > > */
> > > > @@ -4728,6 +4774,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)
> > > > @@ -4743,6 +4790,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_limits(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 5f8c3389d46f..a27a84270d8d 100644
> > > > --- a/include/drm/drm_connector.h
> > > > +++ b/include/drm/drm_connector.h
> > > > @@ -254,6 +254,26 @@ 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
> > > > + * @pixel_clock_mhz: This is the dotclock in MHz from
> > > > + * EDID's detailed monitor range
> > > > + */
> > > > +struct drm_adaptive_sync_info {
> > > > + int min_vfreq;
> > > > + int max_vfreq;
> > > > + int pixel_clock_mhz;
> > >
> > > Any reason why these can't be unsigned? Also, does it perhaps make sense
> > > to store the pixel clock as kHz like we do everywhere else?
> >
> > Aye, all typical clock frequencies should be in khz.
> >
> > Also the vfreqs are only u8 in the EDID, so can be u8 here as well.
>
> Not if you store them in kHz, they can't.
IMO those can stay in Hz. That's what drm_mode_vrefresh() gives you as well.
--
Ville Syrjälä
Intel
More information about the dri-devel
mailing list