From: Daniel Vetter <daniel@ffwll.ch>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 5/9] drm/i915: Clear out DPLL state from pipe config in DSI get config
Date: Tue, 30 Jun 2015 12:13:37 +0200 [thread overview]
Message-ID: <20150630101337.GP30960@phenom.ffwll.local> (raw)
In-Reply-To: <20150629170827.GL5176@intel.com>
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@linux.intel.com wrote:
> > > > From: Ville Syrjälä <ville.syrjala@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@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?
> > 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. Either option is imo clearer than cleaning out
state that we've read.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2015-06-30 10:11 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-29 12:25 [PATCH 0/9] drm/i915: VLV/CHV DPLL workarounds and cleanups ville.syrjala
2015-06-29 12:25 ` [PATCH 1/9] drm/i915: Keep GMCH DPLL VGA mode always disabled ville.syrjala
2015-06-29 14:16 ` Sivakumar Thulasimani
2015-06-29 14:31 ` Ville Syrjälä
2015-06-29 12:25 ` [PATCH 2/9] drm/i915: Apply OCD to VLV/CHV DPLL defines ville.syrjala
2015-06-29 14:21 ` Sivakumar Thulasimani
2015-06-29 12:25 ` [PATCH 3/9] drm/i915: Simplify CHV pipe A power well code ville.syrjala
2015-07-10 11:13 ` Sivakumar Thulasimani
2015-06-29 12:25 ` [PATCH 4/9] drm/i915: Refactor VLV display power well init/deinit ville.syrjala
2015-07-10 11:22 ` Sivakumar Thulasimani
2015-06-29 12:25 ` [PATCH 5/9] drm/i915: Clear out DPLL state from pipe config in DSI get config ville.syrjala
2015-06-29 16:42 ` Daniel Vetter
2015-06-29 16:56 ` Ville Syrjälä
2015-06-29 17:08 ` Ville Syrjälä
2015-06-30 10:13 ` Daniel Vetter [this message]
2015-06-30 11:50 ` Ville Syrjälä
2015-07-01 12:42 ` Daniel Vetter
2015-07-10 12:07 ` Sivakumar Thulasimani
2015-07-13 8:51 ` Daniel Vetter
2015-07-13 10:19 ` Sivakumar Thulasimani
2015-07-13 14:39 ` Daniel Vetter
2015-07-10 11:45 ` Sivakumar Thulasimani
2015-06-29 12:25 ` [PATCH 6/9] drm/i915: Move DPLL ref/cri/VGA mode frobbing to the disp2d well enable ville.syrjala
2015-07-10 12:33 ` Sivakumar Thulasimani
2015-08-26 12:34 ` Daniel Vetter
2015-06-29 12:25 ` [PATCH 7/9] drm/i915: Make {vlv, chv}_{disable, update}_pll() more similar ville.syrjala
2015-06-29 12:25 ` [PATCH 8/9] drm/i915: Implement WaPixelRepeatModeFixForC0:chv ville.syrjala
2015-07-13 6:14 ` Sivakumar Thulasimani
2015-08-10 16:01 ` Ville Syrjälä
2015-06-29 12:25 ` [PATCH 9/9] drm/i915: Disable DSI PLL before reconfiguring it ville.syrjala
2015-07-13 6:17 ` Sivakumar Thulasimani
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150630101337.GP30960@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=intel-gfx@lists.freedesktop.org \
--cc=ville.syrjala@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.