From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 2/2] drm/i915: Allow PCH DPLL sharing regardles of DPLL_SDVO_HIGH_SPEED
Date: Thu, 3 Dec 2015 13:21:42 +0200 [thread overview]
Message-ID: <20151203112142.GF4437@intel.com> (raw)
In-Reply-To: <20151203103720.GE4437@intel.com>
On Thu, Dec 03, 2015 at 12:37:20PM +0200, Ville Syrjälä wrote:
> On Thu, Dec 03, 2015 at 09:02:12AM +0100, Daniel Vetter wrote:
> > On Wed, Nov 25, 2015 at 04:35:31PM +0200, ville.syrjala@linux.intel.com wrote:
> > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > >
> > > DPLL_SDVO_HIGH_SPEED must be set for SDVO/HDMI/DP, but nowhere is it
> > > forbidden to set it for LVDS/CRT as well. So let's move it out of the
> > > ironlake_compute_dpll() and just do it on demand in the pll enable hook.
> > > This allows the PLL to be shared in more cases when dealing with
> > > different output types.
> > >
> > > Note that we must now call the pll enable hook regarless of the current
> > > pll state, so that DPLL_SDVO_HIGH_SPEED gets updated appropriately.
> > >
> > > FIXME: maybe better to add a separate hook for the "pll already enabled"
> > > case?
> > >
> > > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > ---
> > > drivers/gpu/drm/i915/intel_display.c | 29 +++++++++++++++++++++--------
> > > 1 file changed, 21 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> > > index 26cafeea2845..ae58f1105458 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -1908,6 +1908,8 @@ static void intel_enable_shared_dpll(struct intel_crtc *crtc)
> > > if (pll->active++) {
> > > WARN_ON(!pll->on);
> > > assert_shared_dpll_enabled(dev_priv, pll);
> > > + /* to update high speed IO clock state */
> > > + pll->enable(dev_priv, pll);
> > > return;
> > > }
> > > WARN_ON(pll->on);
> > > @@ -8942,11 +8944,6 @@ static uint32_t ironlake_compute_dpll(struct intel_crtc *intel_crtc,
> > > dpll |= (crtc_state->pixel_multiplier - 1)
> > > << PLL_REF_SDVO_HDMI_MULTIPLIER_SHIFT;
> > >
> > > - if (is_sdvo)
> > > - dpll |= DPLL_SDVO_HIGH_SPEED;
> > > - if (crtc_state->has_dp_encoder)
> > > - dpll |= DPLL_SDVO_HIGH_SPEED;
> > > -
> > > /* compute bitmask from p1 value */
> > > dpll |= (1 << (crtc_state->dpll.p1 - 1)) << DPLL_FPA01_P1_POST_DIV_SHIFT;
> > > /* also FPA1 */
> > > @@ -13626,7 +13623,7 @@ static bool ibx_pch_dpll_get_hw_state(struct drm_i915_private *dev_priv,
> > > return false;
> > >
> > > val = I915_READ(PCH_DPLL(pll->id));
> > > - hw_state->dpll = val;
> > > + hw_state->dpll = val & ~DPLL_SDVO_HIGH_SPEED;
> > > hw_state->fp0 = I915_READ(PCH_FP0(pll->id));
> > > hw_state->fp1 = I915_READ(PCH_FP1(pll->id));
> > >
> > > @@ -13643,10 +13640,26 @@ static void ibx_pch_dpll_mode_set(struct drm_i915_private *dev_priv,
> > > static void ibx_pch_dpll_enable(struct drm_i915_private *dev_priv,
> > > struct intel_shared_dpll *pll)
> > > {
> > > + struct drm_device *dev = dev_priv->dev;
> > > + struct intel_crtc *crtc;
> > > + u32 dpll = pll->config.hw_state.dpll;
> > > +
> > > + /* Configure high speed IO clock as needed */
> > > + for_each_intel_crtc(dev, crtc) {
> > > + if (intel_crtc_to_shared_dpll(crtc) == pll &&
> > > + crtc->config->base.active &&
> > > + (crtc->config->has_dp_encoder ||
> > > + intel_pipe_has_type(crtc, INTEL_OUTPUT_SDVO) ||
> > > + intel_pipe_has_type(crtc, INTEL_OUTPUT_HDMI))) {
> > > + dpll |= DPLL_SDVO_HIGH_SPEED;
> > > + break;
> > > + }
> > > + }
> >
> > This is a bit ugly. What about adding a needs_5x_clock to struct
> > intel_shared_dpll_config (i.e. outside of the hw pll state to avoid
> > unsharing and pipe checker warnings)? ilk_compute_dpll would set that, and
> > this function here obeys.
> >
> > Clearing would only happen when we completely disable a pll after the last
> > user is gone.
>
> I don't really like potentially wasting power like that. I suppose it's
> a miniscule amount most likely, but still feels a bit wrong.
Hmm. I wonder if I could make it a bitmask of some sort...
--
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2015-12-03 11:21 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-25 14:35 [PATCH 1/2] drm/i915: Use intel_pipe_will_have_type() in ironlake_crtc_compute_clock() ville.syrjala
2015-11-25 14:35 ` [PATCH 2/2] drm/i915: Allow PCH DPLL sharing regardles of DPLL_SDVO_HIGH_SPEED ville.syrjala
2015-11-26 8:41 ` Daniel Vetter
2015-11-26 11:42 ` Ville Syrjälä
2015-12-01 14:16 ` Ville Syrjälä
2015-12-03 8:02 ` Daniel Vetter
2015-12-03 10:37 ` Ville Syrjälä
2015-12-03 11:21 ` Ville Syrjälä [this message]
2015-11-26 8:40 ` [PATCH 1/2] drm/i915: Use intel_pipe_will_have_type() in ironlake_crtc_compute_clock() Daniel Vetter
2015-12-01 14:10 ` Ville Syrjälä
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=20151203112142.GF4437@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=daniel@ffwll.ch \
--cc=intel-gfx@lists.freedesktop.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox