On Tue, May 13, 2014 at 02:53:22PM -0700, Jesse Barnes wrote:
> On Tue, 13 May 2014 22:26:08 +0200
> Daniel Vetter <daniel@xxxxxxxx> wrote:
>
> > On Tue, May 13, 2014 at 11:51:11AM -0700, clinton.a.taylor@xxxxxxxxx wrote:
> > > From: Clint Taylor <Clinton.A.Taylor@xxxxxxxxx>
> > >
> > > The panel power sequencer on vlv doesn't appear to accept changes to its T12 power down duration during warm reboots. This change forces a delay for warm reboots to the T12 panel timing as defined in the VBT table for the connected panel.
> > >
> > > Signed-off-by: Clint Taylor <clinton.a.taylor@xxxxxxxxx>
> > > ---
> > > drivers/gpu/drm/i915/intel_dp.c | 43 ++++++++++++++++++++++++++++++++++++++
> > > drivers/gpu/drm/i915/intel_drv.h | 1 +
> > > 2 files changed, 44 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> > > index 5ca68aa9..03ac64f 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > @@ -28,6 +28,8 @@
> > > #include <linux/i2c.h>
> > > #include <linux/slab.h>
> > > #include <linux/export.h>
> > > +#include <linux/notifier.h>
> > > +#include <linux/reboot.h>
> > > #include <drm/drmP.h>
> > > #include <drm/drm_crtc.h>
> > > #include <drm/drm_crtc_helper.h>
> > > @@ -302,6 +304,39 @@ static u32 _pp_stat_reg(struct intel_dp *intel_dp)
> > > return VLV_PIPE_PP_STATUS(vlv_power_sequencer_pipe(intel_dp));
> > > }
> > >
> > > +/* Reboot notifier handler to shutdown panel power to gaurantee T12 timing */
> > > +static int edp_notify_handler(struct notifier_block *this, unsigned long code,
> > > + void *unused)
> > > +{
> > > + struct intel_dp *intel_dp = container_of(this, typeof(* intel_dp),
> > > + edp_notifier);
> > > + struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> > > + struct drm_device *dev = intel_dig_port->base.base.dev;
> > > + struct drm_i915_private *dev_priv = dev->dev_private;
> > > + u32 pp;
> > > + u32 pp_ctrl_reg, pp_div_reg;
> > > + enum pipe pipe = vlv_power_sequencer_pipe(intel_dp);
> > > +
> > > + if (!is_edp(intel_dp))
> > > + return 0;
> > > +
> > > + if (IS_VALLEYVIEW(dev)) {
> > > + pp_ctrl_reg = VLV_PIPE_PP_CONTROL(pipe);
> > > + pp_div_reg = VLV_PIPE_PP_DIVISOR(pipe);
> > > + if (code == SYS_RESTART) {
> > > + pr_crit("eDP Notifier Handler\n");
> > > + pp = I915_READ(VLV_PIPE_PP_DIVISOR(pipe));
> > > + pp &= PP_REFERENCE_DIVIDER_MASK;
> > > + I915_WRITE(pp_div_reg , pp | 0x1F);
> > > + I915_WRITE(pp_ctrl_reg,
> > > + PANEL_UNLOCK_REGS | PANEL_POWER_OFF);
> > > + /* VBT entries are in tenths of uS convert to mS */
> > > + msleep(dev_priv->vbt.edp_pps.t11_t12 / 10);
> >
> > Imo just compute the desired delay before setting up this reboot handler
> > and pass it as the argument.
> >
> > But that leaves a bit the question why we don't need that everywhere else
> > and what exactly this does? I'm a bit confused with the commit message.
> > -Daniel
>
> We could potentially do it on other platforms, but it's really only
> needed on those that don't do any display stuff in the BIOS (e.g.
> Chromebooks). In that case, a warm reboot might immediately jump back
> to driver init, and if we haven't full done a PPS, we'll get into
> trouble and potentially confuse the panel in the worst case.
>
> Previous BIOS-free systems may have had this problem too, but this was
> the first one we got an actual eDP timing spec violation about, so it's
> a good first step. It can easily be extended as needed.
>
> Computing the delay ahead of time in eDP init would make it more
> platform agnostic, and we could key off a separate flag as to whether
> the delay was needed, but the above is pretty simple too, albeit VLV
> specific.
>
> The pr_crit() could probably be dropped though, and the magic 0x1f
> needs a comment.
In that case I think rolling this out everywhere can't hurt. Gives us a
notch more testing and rebooting tends to not be a performance critical
thing really.
Otoh I've thought the hardware ensure that the t12 timing is obeyed under
all cases? Does that get lost in the reset?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
