[Intel-gfx] [PATCH 5/9] drm/i915: Clear out DPLL state from pipe config in DSI get config

[Ville Syrjälä]

On Tue, Jun 30, 2015 at 12:13:37PM +0200, Daniel Vetter wrote:
> On Mon, Jun 29, 2015 at 08:08:27PM +0300, Ville Syrjälä wrote:
> > On Mon, Jun 29, 2015 at 07:56:05PM +0300, Ville Syrjälä wrote:
> > > On Mon, Jun 29, 2015 at 06:42:11PM +0200, Daniel Vetter wrote:
> > > > On Mon, Jun 29, 2015 at 03:25:52PM +0300, ville.syrjala at linux.intel.com wrote:
> > > > > From: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > > > > 
> > > > > VLV/CHV don't use the DPLL with DSI, so just clear out the DPLL state
> > > > > from the pipe_config in intel_dsi_get_config(). This avoids spurious
> > > > > state checker warnings. We already did it this way for DPLL_MD, but do
> > > > > it for DPLL too.
> > > > > 
> > > > > Toss in a WARN to intel_dsi_pre_enable() to make sure the ref clocks
> > > > > are enabled however. Supposedly they have some meaning to DSI too.
> > > > > We now keep the ref clocks always enabled while the disp2d well is
> > > > > enabled.
> > > > > 
> > > > > Signed-off-by: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > > > > ---
> > > > >  drivers/gpu/drm/i915/intel_dsi.c | 15 +++++----------
> > > > >  1 file changed, 5 insertions(+), 10 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
> > > > > index 36e2148..92bb252 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_dsi.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_dsi.c
> > > > > @@ -421,18 +421,12 @@ static void intel_dsi_pre_enable(struct intel_encoder *encoder)
> > > > >  
> > > > >  	/* Disable DPOunit clock gating, can stall pipe
> > > > >  	 * and we need DPLL REFA always enabled */
> > > > > -	tmp = I915_READ(DPLL(pipe));
> > > > > -	tmp |= DPLL_REF_CLK_ENABLE_VLV;
> > > > > -	I915_WRITE(DPLL(pipe), tmp);
> > > > > -
> > > > > -	/* update the hw state for DPLL */
> > > > > -	intel_crtc->config->dpll_hw_state.dpll = DPLL_INTEGRATED_REF_CLK_VLV |
> > > > > -		DPLL_REF_CLK_ENABLE_VLV | DPLL_VGA_MODE_DIS;
> > > > > -
> > > > >  	tmp = I915_READ(DSPCLK_GATE_D);
> > > > >  	tmp |= DPOUNIT_CLOCK_GATE_DISABLE;
> > > > >  	I915_WRITE(DSPCLK_GATE_D, tmp);
> > > > >  
> > > > > +	WARN_ON((I915_READ(DPLL(pipe)) & DPLL_REF_CLK_ENABLE_VLV) == 0);
> > > > > +
> > > > >  	/* put device in ready state */
> > > > >  	intel_dsi_device_ready(encoder);
> > > > >  
> > > > > @@ -635,9 +629,10 @@ static void intel_dsi_get_config(struct intel_encoder *encoder,
> > > > >  	DRM_DEBUG_KMS("\n");
> > > > >  
> > > > >  	/*
> > > > > -	 * DPLL_MD is not used in case of DSI, reading will get some default value
> > > > > -	 * set dpll_md = 0
> > > > > +	 * DPLL is not used in case of DSI, reading will getsome default value.
> > > > > +	 * Clear the state to keep the state checker happy.
> > > > >  	 */
> > > > > +	pipe_config->dpll_hw_state.dpll = 0;
> > > > >  	pipe_config->dpll_hw_state.dpll_md = 0;
> > > > 
> > > > State configs are supposed to be kzallocated. Needing this indicates a
> > > > pretty serious bug - I'd vote to instead also ditch the dpll_md line and
> > > > fix the offender.
> > > 
> > > There is no offender really. We read out the DPLL state before we know
> > > which ports are active and hence can't tell at that point if the
> > > information is really relevant.
> 
> So the bios leaves the DPLL enabled even when using a DSI port? Or do we
> miss to check some routing bits in get_clock?

Not necessarily enabled, but there are other bits in there that could be
left in any state basically. The DSI port simply doesn't care.

> > > The alternative would be to explicitly program the DPLL to a specific
> > > state for DSI. That is, we could just call {vlv,chv}_disable_pll()
> > > from  crtc_enable when the pipe is driving a DSI port), and have
> > > intel_dsi_compute_config() fill in an identical state.
> > 
> > Or I suppose we could move clock readout to the encoder
> > .get_config() entirely.
> 
> Yeah either that or do a crtc sanitize to fixup the DPLL that's somehow
> enabled but not needed.

To do that properly we should just expose all the PLLs as "shared" PLLs.
I don't really want to add a VLV/CHV specific hack for that.

> Either option is imo clearer than cleaning out
> state that we've read.
> -Daniel
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

-- 
Ville Syrjälä
Intel OTC