2014-07-14 16:10 GMT-03:00 Todd Previte <tprevite@xxxxxxxxx>: > Add a simple function to pull the preferred mode out of an EDID block. This function > is designed for use during Displayport compliance testing. > The preferred mode can be changed by the quirks. Do you think that could be a problem? Also, as said earlier, this should be squashed in patch 7. > Signed-off-by: Todd Previte <tprevite@xxxxxxxxx> > --- > drivers/gpu/drm/i915/intel_dp.c | 25 +++++++++++++++++++++++++ > 1 file changed, 25 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c > index f61502e..6c8f222 100644 > --- a/drivers/gpu/drm/i915/intel_dp.c > +++ b/drivers/gpu/drm/i915/intel_dp.c > @@ -3351,6 +3351,31 @@ static bool intel_dp_compute_edid_checksum(uint8_t *edid_data, uint8_t *edid_che > return edid_ok; > } > > +static struct drm_display_mode* One of the inconsistencies with our driver is that we have both "return_type \n function_name" and "return_type function_name" (on the same line). I wish we were consistent. Anyway, I'd add a space between "_mode" and '*' > +intel_dp_get_edid_preferred_mode(struct intel_dp *intel_dp) > +{ > + struct drm_display_mode *found_mode = NULL; > + struct drm_connector *connector = &intel_dp->attached_connector->base; > + int mode_count = 0; > + > + list_for_each_entry(found_mode, &connector->probed_modes, head) { > + /* Check for a preferred mode */ > + if (found_mode->type & DRM_MODE_TYPE_PREFERRED) { > + /* Found the preferred mode, return it */ > + DRM_DEBUG_KMS("Displayport: Found preferred mode '%s'\n", > + found_mode->name); > + goto exit_with_mode; > + } > + mode_count++; > + } > + /* No mode found, report the error */ > + DRM_DEBUG_KMS("Displayport: Preferred mode not found in %d probed modes\n", > + mode_count); > + > +exit_with_mode: > + return found_mode; > +} > + > /* Displayport compliance testing - Link training */ > static uint8_t > intel_dp_autotest_link_training(struct intel_dp *intel_dp) > -- > 1.9.1 > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Paulo Zanoni _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx