From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Vivek Kasireddy <vivek.kasireddy@intel.com>
Cc: intel-gfx@lists.freedesktop.org,
Lucas De Marchi <lucas.demarchi@intel.com>
Subject: Re: [PATCH] drm/i915/ehl: Add support for DPLL4 (v3)
Date: Wed, 10 Apr 2019 20:57:20 +0300 [thread overview]
Message-ID: <20190410175720.GO3888@intel.com> (raw)
In-Reply-To: <20190409170044.66f8e92e@vkasired-desk2.fm.intel.com>
On Tue, Apr 09, 2019 at 05:00:44PM -0700, Vivek Kasireddy wrote:
> On Mon, 8 Apr 2019 12:11:15 +0300
> Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> Hi,
>
> > On Fri, Apr 05, 2019 at 04:33:30PM -0700, Vivek Kasireddy wrote:
> > > On Fri, 5 Apr 2019 21:39:11 +0300
> > > Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> > > Hi Ville,
> > >
> > > > On Fri, Apr 05, 2019 at 09:33:56PM +0300, Ville Syrjälä wrote:
> > > > > On Fri, Apr 05, 2019 at 10:59:53AM -0700, Vivek Kasireddy
> > > > > wrote:
> > > > > > This patch adds support for DPLL4 on EHL that include the
> > > > > > following restrictions:
> > > > > >
> > > > > > - DPLL4 cannot be used with DDIA (combo port A internal eDP
> > > > > > usage). DPLL4 can be used with other DDIs, including DDID
> > > > > > (combo port A external usage).
> > > > > >
> > > > > > - DPLL4 cannot be enabled when DC5 or DC6 are enabled.
> > > > > >
> > > > > > - The DPLL4 enable, lock, power enabled, and power state are
> > > > > > connected to the MGPLL1_ENABLE register.
> > > > > >
> > > > > > v2: (suggestions from Bob Paauwe)
> > > > > > - Rework ehl_get_dpll() function to call
> > > > > > intel_find_shared_dpll() and iterate twice: once for Combo
> > > > > > plls and once for MG plls.
> > > > > >
> > > > > > - Use MG pll funcs for DPLL4 instead of creating new ones and
> > > > > > modify mg_pll_enable to include the restrictions for EHL.
> > > > > >
> > > > > > v3: Fix compilation error
> > > > > >
> > > > > > Cc: Lucas De Marchi <lucas.demarchi@intel.com>
> > > > > > Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
> > > > > > Reviewed-by: Bob Paauwe <bob.j.paauwe@intel.com>
> > > > > > ---
> > > > > > drivers/gpu/drm/i915/intel_dpll_mgr.c | 60
> > > > > > ++++++++++++++++++++++++++++++++++- 1 file changed, 59
> > > > > > insertions(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > > > > > b/drivers/gpu/drm/i915/intel_dpll_mgr.c index
> > > > > > e01c057ce50b..c3f0b9720c54 100644 ---
> > > > > > a/drivers/gpu/drm/i915/intel_dpll_mgr.c +++
> > > > > > b/drivers/gpu/drm/i915/intel_dpll_mgr.c @@ -2870,6 +2870,56 @@
> > > > > > icl_get_dpll(struct intel_crtc_state *crtc_state, return pll;
> > > > > > }
> > > > > >
> > > > > > +static struct intel_shared_dpll *
> > > > > > +ehl_get_dpll(struct intel_crtc_state *crtc_state,
> > > > > > + struct intel_encoder *encoder)
> > > > > > +{
> > > > > > + struct drm_i915_private *dev_priv =
> > > > > > to_i915(crtc_state->base.crtc->dev);
> > > > > > + struct intel_shared_dpll *pll;
> > > > > > + enum port port = encoder->port;
> > > > > > + enum intel_dpll_id min, max;
> > > > > > + bool ret;
> > > > > > +
> > > > > > + if (!intel_port_is_combophy(dev_priv, port)) {
> > > > > > + MISSING_CASE(port);
> > > > > > + return NULL;
> > > > > > + }
> > > > > > +
> > > > > > + min = DPLL_ID_ICL_DPLL0;
> > > > > > + max = DPLL_ID_ICL_DPLL1;
> > > > > > + ret = icl_calc_dpll_state(crtc_state, encoder);
> > > > > > + if (ret) {
> > > > > > + pll = intel_find_shared_dpll(crtc_state, min,
> > > > > > max);
> > > > > > + if (pll) {
> > > > > > + intel_reference_shared_dpll(pll,
> > > > > > crtc_state);
> > > > > > + return pll;
> > > > > > + }
> > > > > > + } else {
> > > > > > + DRM_DEBUG_KMS("Could not calculate PLL
> > > > > > state.\n");
> > > > > > + }
> > > > > > +
> > > > > > + if (encoder->type == INTEL_OUTPUT_EDP) {
> > > > > > + DRM_DEBUG_KMS("Cannot use DPLL4 with
> > > > > > EDP.\n");
> > > > > > + return NULL;
> > > > > > + }
> > > > > > +
> > > > > > + min = max = DPLL_ID_ICL_MGPLL1;
> > > > > > + ret = icl_calc_mg_pll_state(crtc_state);
> > > > > > + if (!ret) {
> > > > > > + DRM_DEBUG_KMS("Could not calculate PLL
> > > > > > state.\n");
> > > > > > + return NULL;
> > > > > > + }
> > > > > > +
> > > > > > + pll = intel_find_shared_dpll(crtc_state, min, max);
> > > > > > + if (!pll) {
> > > > > > + DRM_DEBUG_KMS("No PLL selected\n");
> > > > > > + return NULL;
> > > > > > + }
> > > > > > +
> > > > > > + intel_reference_shared_dpll(pll, crtc_state);
> > > > > > + return pll;
> > > > > > +}
> > > > > > +
> > > > > > static bool mg_pll_get_hw_state(struct drm_i915_private
> > > > > > *dev_priv, struct intel_shared_dpll *pll,
> > > > > > struct intel_dpll_hw_state
> > > > > > *hw_state) @@ -3115,6 +3165,13 @@ static void
> > > > > > mg_pll_enable(struct drm_i915_private *dev_priv, i915_reg_t
> > > > > > enable_reg =
> > > > > > MG_PLL_ENABLE(icl_pll_id_to_tc_port(pll->info->id));
> > > > > > + if (IS_ELKHARTLAKE(dev_priv) &&
> > > > > > + (I915_READ(DC_STATE_EN) & DC_STATE_EN_UPTO_DC5 ||
> > > > > > + I915_READ(DC_STATE_EN) & DC_STATE_EN_UPTO_DC6)) {
> > > > > > + DRM_ERROR("Cant enable DPLL4 when DC5 or DC6
> > > > > > are enabled\n");
> > > > > > + return;
> > > > > > + }
> > > > >
> > > > > This looks like dead code, or we messed up earlier already (in
> > > > > which case it should just be some kind of assert IMO).
> > > Are you suggesting that I put this in a ->prepare() hook or much
> > > earlier in the atomic check/prepare phase? FYI, I am just adding a
> > > restriction mentioned in the spec concerning this DPLL.
> > >
> > > >
> > > > Does DMC handle other MG PLLs? I would have thought not, so if we
> > > > keep the assert then it should perhaps be unconditional. Hmm. But
> > > > aren't we still hodling the modeset power domain when this gets
> > > > called? If so this is definitely dead code.
> > > I am not sure whether DMC handles other MG PLLs but the spec
> > > explicitly says that DMC will not handle this PLL. Where do you
> > > suggest is an appropriate place to put this assert?
> >
> > DC5/6 enable probably is the best, if we even want the assert. And I'm
> > not convinced that we do since we don't have it for any other PLL
> > either.
> As I mentioned earlier, the spec says we cannot enable this DPLL for EHL
> if DC5 or DC6 is enabled. Do you think we should disable DC5/DC6 on EHL
> in order to enable this DPLL on EHL? Should the user/system integrator
> be making that decision via a module parameter?
If there is some way that could happen currently, then we need to
prevent DC5/6 via some power domain stuff.
--
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2019-04-10 17:57 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-04 23:22 [PATCH] drm/i915/ehl: Add support for DPLL4 (v2) Vivek Kasireddy
2019-04-05 0:06 ` ✗ Fi.CI.BAT: failure for " Patchwork
2019-04-05 17:59 ` [PATCH] drm/i915/ehl: Add support for DPLL4 (v3) Vivek Kasireddy
2019-04-05 18:33 ` Ville Syrjälä
2019-04-05 18:39 ` Ville Syrjälä
2019-04-05 23:33 ` Vivek Kasireddy
2019-04-08 9:11 ` Ville Syrjälä
2019-04-10 0:00 ` Vivek Kasireddy
2019-04-10 17:57 ` Ville Syrjälä [this message]
2019-04-06 0:46 ` Lucas De Marchi
2019-04-09 23:56 ` Vivek Kasireddy
2019-04-11 23:36 ` [PATCH] drm/i915/ehl: Add support for DPLL4 (v4) Vivek Kasireddy
2019-04-16 20:11 ` Bob Paauwe
2019-04-17 13:06 ` Ville Syrjälä
2019-04-23 22:53 ` Vivek Kasireddy
2019-04-05 19:23 ` ✗ Fi.CI.CHECKPATCH: warning for drm/i915/ehl: Add support for DPLL4 (v3) Patchwork
2019-04-05 19:44 ` ✓ Fi.CI.BAT: success " Patchwork
2019-04-06 17:53 ` ✗ Fi.CI.IGT: failure " Patchwork
2019-04-12 1:37 ` ✓ Fi.CI.BAT: success for drm/i915/ehl: Add support for DPLL4 (v3) (rev2) Patchwork
2019-04-12 11:10 ` ✓ Fi.CI.IGT: " Patchwork
2019-04-05 4:23 ` [PATCH] drm/i915/ehl: Add support for DPLL4 (v2) kbuild test robot
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=20190410175720.GO3888@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=lucas.demarchi@intel.com \
--cc=vivek.kasireddy@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).