On Mon, May 21, 2012 at 06:49:18PM -0700, Keith Packard wrote:
> Daniel Vetter <dan...@ffwll.ch> writes:
>
> >> --- a/drivers/gpu/drm/i915/intel_dp.c
> >> +++ b/drivers/gpu/drm/i915/intel_dp.c
> >> @@ -1154,11 +1154,10 @@ static void ironlake_edp_panel_off(struct intel_dp
> >> *intel_dp)
> >>
> >> DRM_DEBUG_KMS("Turn eDP power off\n");
> >>
> >> - WARN(intel_dp->want_panel_vdd, "Cannot turn power off while VDD is
> >> on\n");
> >> - ironlake_panel_vdd_off_sync(intel_dp); /* finish any pending work */
> >> + WARN(!intel_dp->want_panel_vdd, "Need VDD to turn off panel\n");
> >>
> >> pp = ironlake_get_pp_control(dev_priv);
> >> - pp &= ~(POWER_TARGET_ON | EDP_FORCE_VDD | PANEL_POWER_RESET |
> >> EDP_BLC_ENABLE);
> >> + pp &= ~(POWER_TARGET_ON | PANEL_POWER_RESET | EDP_BLC_ENABLE);
>
> Can you explain where the panel is getting turned off here?
Well, before this change the edp power off sequence was:
- switch vdd off (or more precise: ensure it's off)
- switch backlight off
- switch panel power off (i.e. the above function)
Now the new sequence is (always with the right amounts of delays,
obviously):
- switch vdd on
- switch backlight off
- switch panel off
- switch vdd off
That's why I've had to remove the EDP_FORCE_VDD bit from the above
bitfrobbing, because we now want vdd to stay on while we do the power
sequence above.
The reason is that we have a callchain (in intel_dp_prepare) where we do
some aux channel communication after having switched off the panel. And
that needs vdd, but because edp_panel_off killed that, things got
confused.
-Daniel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
