From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Ander Conselvan De Oliveira <conselvan2@gmail.com>
Cc: Nick Yamane <nick.diego@gmail.com>,
Daniel Vetter <daniel.vetter@ffwll.ch>,
intel-gfx@lists.freedesktop.org, stable@vger.kernel.org
Subject: Re: [PATCH] drm/i915: Allow PCH DPLL sharing regardless of DPLL_SDVO_HIGH_SPEED
Date: Wed, 28 Sep 2016 14:43:41 +0300 [thread overview]
Message-ID: <20160928114341.GN4329@intel.com> (raw)
In-Reply-To: <1475062339.5813.5.camel@gmail.com>
On Wed, Sep 28, 2016 at 02:32:19PM +0300, Ander Conselvan De Oliveira wrote:
> On Mon, 2016-09-26 at 11:30 +0300, 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 also set it on
> > CRT to make it possible to share the DPLL between HDMI and CRT.
> >
> > What that bit apparently does is enable the x5 clock to the port,
> > which then pumps out the bits on both edges of the clock. The DAC
> > doesn't need that clock since it's not pumping out bits, but I don't
> > think it hurts to have the DPLL output that clock anyway.
> >
> > This is fairly important on IVB since it has only two DPLLs with three
> > pipes. So trying to drive three or more PCH ports with three pipes
> > is only possible when at least one of the DPLLs gets shared between
> > two of the pipes.
> >
> > SNB doesn't really need to do this since it has only two pipes. It could
> > be done to avoid enabling the second DPLL at all in certain cases, but
> > I'm not sure that's such a huge win. So let's not do it for SNB, at
> > least for now. On ILK it never makes sense as the DPLLs can't be shared.
> >
> > v2: Just always enable the high speed clock to keep things simple (Daniel)
> > Beef up the commit message a bit (Daniel)
> >
> > Cc: Nick Yamane <nick.diego@gmail.com>
> > Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> > Cc: stable@vger.kernel.org
> > Tested-by: Nick Yamane <nick.diego@gmail.com>
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97204
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 18 ++++++++++++++++++
> > 1 file changed, 18 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index e5ad1010c8b1..45ff5007544c 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -9512,6 +9512,24 @@ static void ironlake_compute_dpll(struct intel_crtc
> > *intel_crtc,
> > if (intel_crtc_has_dp_encoder(crtc_state))
> > dpll |= DPLL_SDVO_HIGH_SPEED;
> >
> > + /*
> > + * The high speed IO clock is only really required for
> > + * SDVO/HDMI/DP, but we also enable it for CRT to make it
> > + * possible to share the DPLL between CRT and HDMI. Enabling
> > + * the clock needlessly does no real harm, except use up a
> > + * bit of power potentially.
>
> I guess we could have a smarter way to check if two configurations are
> compatible than the current memcmp(). I.e., a platform hook that takes two PLL
> configs and either returns a merged configuration that satisfy both or signal
> failure. That way we could only enable the high speed clock for CRT if really
> necessary.
>
> But meh, sounds like too much work for very little gain.
Yeah. I did implement something more fancy for this (tracking it with a
refcount outside the state we memcmp()), but it was quite a lot of code
for just this little thing. So I decided that I'd rather not have to
debug it if/when it breaks.
>
> The documentation indeed doesn't say anything about not enabling this with CRT,
> so
>
> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
>
> > + *
> > + * We'll limit this to IVB with 3 pipes, since it has only two
> > + * DPLLs and so DPLL sharing is the only way to get three pipes
> > + * driving PCH ports at the same time. On SNB we could do this,
> > + * and potentially avoid enabling the second DPLL, but it's not
> > + * clear if it''s a win or loss power wise. No point in doing
> > + * this on ILK at all since it has a fixed DPLL<->pipe mapping.
> > + */
> > + if (INTEL_INFO(dev_priv)->num_pipes == 3 &&
> > + intel_crtc_has_type(crtc_state, INTEL_OUTPUT_ANALOG))
> > + 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 */
--
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
WARNING: multiple messages have this Message-ID (diff)
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Ander Conselvan De Oliveira <conselvan2@gmail.com>
Cc: intel-gfx@lists.freedesktop.org,
Nick Yamane <nick.diego@gmail.com>,
Daniel Vetter <daniel.vetter@ffwll.ch>,
stable@vger.kernel.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Allow PCH DPLL sharing regardless of DPLL_SDVO_HIGH_SPEED
Date: Wed, 28 Sep 2016 14:43:41 +0300 [thread overview]
Message-ID: <20160928114341.GN4329@intel.com> (raw)
In-Reply-To: <1475062339.5813.5.camel@gmail.com>
On Wed, Sep 28, 2016 at 02:32:19PM +0300, Ander Conselvan De Oliveira wrote:
> On Mon, 2016-09-26 at 11:30 +0300, 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 also set it on
> > CRT to make it possible to share the DPLL between HDMI and CRT.
> >
> > What that bit apparently does is enable the x5 clock to the port,
> > which then pumps out the bits on both edges of the clock. The DAC
> > doesn't need that clock since it's not pumping out bits, but I don't
> > think it hurts to have the DPLL output that clock anyway.
> >
> > This is fairly important on IVB since it has only two DPLLs with three
> > pipes. So trying to drive three or more PCH ports with three pipes
> > is only possible when at least one of the DPLLs gets shared between
> > two of the pipes.
> >
> > SNB doesn't really need to do this since it has only two pipes. It could
> > be done to avoid enabling the second DPLL at all in certain cases, but
> > I'm not sure that's such a huge win. So let's not do it for SNB, at
> > least for now. On ILK it never makes sense as the DPLLs can't be shared.
> >
> > v2: Just always enable the high speed clock to keep things simple (Daniel)
> > ����Beef up the commit message a bit (Daniel)
> >
> > Cc: Nick Yamane <nick.diego@gmail.com>
> > Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> > Cc: stable@vger.kernel.org
> > Tested-by: Nick Yamane <nick.diego@gmail.com>
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97204
> > Signed-off-by: Ville Syrj�l� <ville.syrjala@linux.intel.com>
> > ---
> > �drivers/gpu/drm/i915/intel_display.c | 18 ++++++++++++++++++
> > �1 file changed, 18 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index e5ad1010c8b1..45ff5007544c 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -9512,6 +9512,24 @@ static void ironlake_compute_dpll(struct intel_crtc
> > *intel_crtc,
> > � if (intel_crtc_has_dp_encoder(crtc_state))
> > � dpll |= DPLL_SDVO_HIGH_SPEED;
> > �
> > + /*
> > + �* The high speed IO clock is only really required for
> > + �* SDVO/HDMI/DP, but we also enable it for CRT to make it
> > + �* possible to share the DPLL between CRT and HDMI. Enabling
> > + �* the clock needlessly does no real harm, except use up a
> > + �* bit of power potentially.
>
> I guess we could have a smarter way to check if two configurations are
> compatible than the current memcmp(). I.e., a platform hook that takes two PLL
> configs and either returns a merged configuration that satisfy both or signal
> failure. That way we could only enable the high speed clock for CRT if really
> necessary.
>
> But meh, sounds like too much work for very little gain.
Yeah. I did implement something more fancy for this (tracking it with a
refcount outside the state we memcmp()), but it was quite a lot of code
for just this little thing. So I decided that I'd rather not have to
debug it if/when it breaks.
>
> The documentation indeed doesn't say anything about not enabling this with CRT,
> so
>
> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
>
> > + �*
> > + �* We'll limit this to IVB with 3 pipes, since it has only two
> > + �* DPLLs and so DPLL sharing is the only way to get three pipes
> > + �* driving PCH ports at the same time. On SNB we could do this,
> > + �* and potentially avoid enabling the second DPLL, but it's not
> > + �* clear if it''s a win or loss power wise. No point in doing
> > + �* this on ILK at all since it has a fixed DPLL<->pipe mapping.
> > + �*/
> > + if (INTEL_INFO(dev_priv)->num_pipes == 3 &&
> > + ����intel_crtc_has_type(crtc_state, INTEL_OUTPUT_ANALOG))
> > + 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 */
--
Ville Syrj�l�
Intel OTC
next prev parent reply other threads:[~2016-09-28 11:43 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-26 8:30 [PATCH] drm/i915: Allow PCH DPLL sharing regardless of DPLL_SDVO_HIGH_SPEED ville.syrjala
2016-09-26 8:30 ` ville.syrjala
2016-09-26 9:23 ` ✗ Fi.CI.BAT: warning for " Patchwork
2016-09-26 9:39 ` Ville Syrjälä
2016-09-28 11:32 ` [PATCH] " Ander Conselvan De Oliveira
2016-09-28 11:32 ` [Intel-gfx] " Ander Conselvan De Oliveira
2016-09-28 11:43 ` Ville Syrjälä [this message]
2016-09-28 11:43 ` Ville Syrjälä
2016-09-28 14:18 ` Ville Syrjälä
2016-09-28 14:18 ` 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=20160928114341.GN4329@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=conselvan2@gmail.com \
--cc=daniel.vetter@ffwll.ch \
--cc=intel-gfx@lists.freedesktop.org \
--cc=nick.diego@gmail.com \
--cc=stable@vger.kernel.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.