2012/10/11 Daniel Vetter <daniel.vetter at ffwll.ch>: > ... since they don't apply to pre-pch platforms and could actually be > harmful. > > Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch> Ok, so I checked the specs and yes, these bit definitions don't exist. The problem here is that instead of "must-be-zero", the spec says "Reserved. Software must preserve the contents of these bits" for bits 29:16 (and also some others). So maybe by setting everything to 0 instead of enabling bits 17, 18, 20-23 we could actually be breaking things? Either way, both the old and new code don't follow the specification. Maybe on non-pch-split we could try to read ADPA and erase all the bits except the "must-be-preserved" ones? > --- > drivers/gpu/drm/i915/intel_crt.c | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c > index c42b980..46c90f5 100644 > --- a/drivers/gpu/drm/i915/intel_crt.c > +++ b/drivers/gpu/drm/i915/intel_crt.c > @@ -235,7 +235,11 @@ static void intel_crt_mode_set(struct drm_encoder *encoder, > dpll_md & ~DPLL_MD_UDI_MULTIPLIER_MASK); > } > > - adpa = ADPA_HOTPLUG_BITS; > + if (HAS_PCH_SPLIT(dev)) > + adpa = ADPA_HOTPLUG_BITS; > + else > + adpa = 0; > + > if (adjusted_mode->flags & DRM_MODE_FLAG_PHSYNC) > adpa |= ADPA_HSYNC_ACTIVE_HIGH; > if (adjusted_mode->flags & DRM_MODE_FLAG_PVSYNC) > -- > 1.7.11.2 > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Paulo Zanoni
