Re: [PATCH 1/6] drm/i915/vlv: assert and de-assert sideband reset at boot and resume v3

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Tue, May 27, 2014 at 10:24:14PM +0200, Daniel Vetter wrote:
> On Tue, May 27, 2014 at 10:32:47PM +0300, Ville Syrjälä wrote:
> > On Fri, May 23, 2014 at 01:16:40PM -0700, Jesse Barnes wrote:
> > > This is a bit like the CMN reset de-assert we do in DPIO_CTL, except
> > > that it resets the whole common lane section of the PHY.  This is
> > > required on machines where the BIOS doesn't do this for us on boot or
> > > resume to properly re-calibrate and get the PHY ready to transmit data.
> > > 
> > > Without this patch, such machines won't resume correctly much of the time,
> > > with the symptom being a 'port ready' timeout and/or a link training
> > > failure.
> > > 
> > > Note that simply asserting reset at suspend and de-asserting at resume
> > > is not sufficient, nor is simply de-asserting at boot.  Both of these
> > > cases have been tested and have still been found to have failures on
> > > some configurations.
> > > 
> > > v2: extract simpler set_power_well function for use in reset_dpio (Imre)
> > >     move to reset_dpio (Daniel & Ville)
> > > v3: don't reset if DPIO reset is already de-asserted (Imre)
> > > 
> > > Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
> > 
> > The series matches my understanding of the limitations of the PHY, so:
> > Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> 
> All merged to dinq, thanks.
>  
> > But if these limitations are real, then I think we would also need to
> > adjust the power domains to power up all the wells whenever even a
> > single one is required.
> > 
> > This should be testable I think by simply:
> > 1. disable both ports
> > 2. enable one port
> > 3. enable the other port
> > 
> > At step 3. the common well is already up, so the TX wells for the second
> > port should come up in some kind of poor state.
> 
> Hm, if we need this we might forc a modeset for _all_ pipes on vlv, even
> for unchanged ports. At elast as long as we enable something new. That
> should make this work properly I hope.

Yeah that would work too, but obviously would cause some blinking that
might be a bit disturbing. But we may have such blinking already due to
adjusting cdclk. If the blinking is disturbing for users we might want
to have a knob for controlling it: either use less power but blink more,
or waste a bit of power and blink less. But I don't know if anyone would
really want to waste power.

-- 
Ville Syrjälä
Intel OTC