From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915/vlv: untangle integrated clock source handling
Date: Fri, 27 Sep 2013 23:09:26 +0300 [thread overview]
Message-ID: <20130927200926.GJ14385@intel.com> (raw)
In-Reply-To: <1380309731-1324-1-git-send-email-jbarnes@virtuousgeek.org>
On Fri, Sep 27, 2013 at 12:22:11PM -0700, Jesse Barnes wrote:
> The global integrated clock source bit resides in DPLL B on VLV, but we
> were treating it as a per-pipe resource. It needs to be set whenever
> any PLL is active,
Actually AFAIU the cri clock has to be running even if we just attempt
to do any register access to the phy.
> so pull setting the bit out of vlv_update_pll and
> into vlv_enable_pll. Also add a vlv_disable_pll to prevent disabling it
> when pipe B shuts down.
>
> I'm guessing on the references here, I expect this to bite any config
> where multiple displays are active or displays are moved from pipe to
> pipe.
>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=67245
> References: https://bugs.freedesktop.org/show_bug.cgi?id=69693
> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
> ---
> drivers/gpu/drm/i915/intel_display.c | 27 ++++++++++++++++++++++++---
> 1 file changed, 24 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index 0eeba84..def2473 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -1386,6 +1386,13 @@ static void vlv_enable_pll(struct intel_crtc *crtc)
> if (IS_MOBILE(dev_priv->dev) && !IS_I830(dev_priv->dev))
> assert_panel_unlocked(dev_priv, crtc->pipe);
>
> + /* Make sure to use the integrated clock source */
> + if (!crtc->pipe)
> + I915_WRITE(DPLL(1), I915_READ(DPLL(1)) |
> + DPLL_INTEGRATED_CRI_CLK_VLV);
We may need the cri clock before this, so I would just put this part
into some modeset hw init function.
> + else
> + dpll |= DPLL_INTEGRATED_CRI_CLK_VLV;
And obviously this part has to stay here, or we could do a
'I915_READ(DPLL(1)) & DPLL_INTEGRATED_CRI_CLK_VLV)' to extract the
current setting from the hardware like you do in vlv_disable_pll().
In any case I think doing it the same way for both enable and
disable would be good.
Or we could leave setting of this bit up to vlv_update_pll() like it was
before.
> +
> I915_WRITE(reg, dpll);
> POSTING_READ(reg);
> udelay(150);
> @@ -1476,6 +1483,20 @@ static void i9xx_disable_pll(struct drm_i915_private *dev_priv, enum pipe pipe)
> POSTING_READ(DPLL(pipe));
> }
>
> +static void vlv_disable_pll(struct drm_i915_private *dev_priv, enum pipe pipe)
> +{
> + u32 val = 0;
> +
> + /* Make sure the pipe isn't still relying on us */
> + assert_pipe_disabled(dev_priv, pipe);
> +
> + /* Leave integrated clock source enabled for the other pipe */
> + if (pipe)
> + val = I915_READ(DPLL(pipe)) & DPLL_INTEGRATED_CRI_CLK_VLV;
Right. As stated we need to either hardcode the bit on (if we assume 1
is the right answer always) or we read it back like you do.
> + I915_WRITE(DPLL(pipe), val);
> + POSTING_READ(DPLL(pipe));
> +}
> +
> void vlv_wait_port_ready(struct drm_i915_private *dev_priv, int port)
> {
> u32 port_mask;
> @@ -3886,7 +3907,9 @@ static void i9xx_crtc_disable(struct drm_crtc *crtc)
> if (encoder->post_disable)
> encoder->post_disable(encoder);
>
> - if (!intel_pipe_has_type(crtc, INTEL_OUTPUT_DSI))
> + if (IS_VALLEYVIEW(dev) && !intel_pipe_has_type(crtc, INTEL_OUTPUT_DSI))
> + vlv_disable_pll(dev_priv, pipe);
> + else if (!IS_VALLEYVIEW(dev))
> i9xx_disable_pll(dev_priv, pipe);
>
> intel_crtc->active = false;
> @@ -4626,8 +4649,6 @@ static void vlv_update_pll(struct intel_crtc *crtc)
> /* Enable DPIO clock input */
> dpll = DPLL_EXT_BUFFER_ENABLE_VLV | DPLL_REFA_CLK_ENABLE_VLV |
> DPLL_VGA_MODE_DIS | DPLL_INTEGRATED_CLOCK_VLV;
> - if (pipe)
> - dpll |= DPLL_INTEGRATED_CRI_CLK_VLV;
>
> dpll |= DPLL_VCO_ENABLE;
> crtc->config.dpll_hw_state.dpll = dpll;
> --
> 1.8.3.1
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
next prev parent reply other threads:[~2013-09-27 20:09 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-27 19:22 [PATCH] drm/i915/vlv: untangle integrated clock source handling Jesse Barnes
2013-09-27 20:02 ` Daniel Vetter
2013-09-27 20:09 ` Ville Syrjälä [this message]
2013-09-27 22:09 ` Jesse Barnes
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=20130927200926.GJ14385@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jbarnes@virtuousgeek.org \
/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.