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@xxxxxxxxxxxxxxx wrote:
> > > > > From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>
> > > > >
> > > > > 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@xxxxxxxxxxxxxxx>
> > > > > ---
> > > > > 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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
