All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v4 1/5] drm/i915/gen11: Start distinguishing 'phy' from 'port'
Date: Thu, 4 Jul 2019 18:09:04 +0300	[thread overview]
Message-ID: <20190704150904.GI5942@intel.com> (raw)
In-Reply-To: <20190704145426.f22rxbbzprj55tew@ldmartin-desk1>

On Thu, Jul 04, 2019 at 07:54:26AM -0700, Lucas De Marchi wrote:
> On Thu, Jul 04, 2019 at 12:18:11PM +0300, Ville Syrjälä wrote:
> >On Wed, Jul 03, 2019 at 04:37:32PM -0700, Matt Roper wrote:
> >> Our past DDI-based Intel platforms have had a fixed DDI<->PHY mapping.
> >> Because of this, both the bspec documentation and our i915 code has used
> >> the term "port" when talking about either DDI's or PHY's; it was always
> >> easy to tell what terms like "Port A" were referring to from the
> >> context.
> >>
> >> Unfortunately this is starting to break down now that EHL allows PHY-A
> >> to be driven by either DDI-A or DDI-D.  Is a setup with DDI-D driving
> >> PHY-A considered "Port A" or "Port D?"  The answer depends on which
> >> register we're working with, and even the bspec doesn't do a great job
> >> of clarifying this.
> >>
> >> Let's try to be more explicit about whether we're talking about the DDI
> >> or the PHY on gen11+ by using 'port' to refer to the DDI and creating a
> >> new 'enum phy' namespace to refer to the PHY in use.
> >>
> >> This patch just adds the new PHY namespace, new phy-based versions of
> >> intel_port_is_*(), and a helper to convert a port to a PHY.
> >> Transitioning various areas of the code over to using the PHY namespace
> >> will be done in subsequent patches to make review easier.  We'll remove
> >> the intel_port_is_*() functions at the end of the series when we
> >> transition all callers over to using the PHY-based versions.
> >>
> >> v2:
> >>  - Convert a few more 'port' uses to 'phy.' (Sparse)
> >>
> >> v3:
> >>  - Switch DDI_CLK_SEL() back to 'port.' (Jose)
> >>  - Add a code comment clarifying why DPCLKA_CFGCR0_ICL needs to use PHY
> >>    for its bit definitions, even though the register description is
> >>    given in terms of DDI.
> >>  - To avoid confusion, switch CNL's DPCLKA_CFGCR0 defines back to using
> >>    port and create separate ICL+ definitions that work in terms of PHY.
> >>
> >> v4:
> >>  - Rebase and resolve conflicts with Imre's TC series.
> >>  - This patch now just adds the namespace and a few convenience
> >>    functions; the important changes are now split out into separate
> >>    patches to make review easier.
> >>
> >> Suggested-by: Ville Syrjala <ville.syrjala@linux.intel.com>
> >> Cc: José Roberto de Souza <jose.souza@intel.com>
> >> Cc: Lucas De Marchi <lucas.demarchi@intel.com>
> >> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >> Cc: Imre Deak <imre.deak@intel.com>
> >> Cc: Jani Nikula <jani.nikula@intel.com>
> >> Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
> >> ---
> >>  drivers/gpu/drm/i915/display/intel_display.c | 32 +++++++++++++++++++-
> >>  drivers/gpu/drm/i915/display/intel_display.h | 16 ++++++++++
> >>  drivers/gpu/drm/i915/intel_drv.h             |  2 ++
> >>  3 files changed, 49 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
> >> index 919f5ac844c8..4a85abef93e7 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_display.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> >> @@ -6663,6 +6663,20 @@ bool intel_port_is_combophy(struct drm_i915_private *dev_priv, enum port port)
> >>  	return false;
> >>  }
> >>
> >> +bool intel_phy_is_combo(struct drm_i915_private *dev_priv, enum phy phy)
> >> +{
> >> +	if (phy == PHY_NONE)
> >> +		return false;
> >> +
> >> +	if (IS_ELKHARTLAKE(dev_priv))
> >> +		return phy <= PHY_C;
> >> +
> >> +	if (INTEL_GEN(dev_priv) >= 11)
> >> +		return phy <= PHY_B;
> >> +
> >> +	return false;
> >> +}
> >> +
> >>  bool intel_port_is_tc(struct drm_i915_private *dev_priv, enum port port)
> >>  {
> >>  	if (INTEL_GEN(dev_priv) >= 11 && !IS_ELKHARTLAKE(dev_priv))
> >> @@ -6671,9 +6685,25 @@ bool intel_port_is_tc(struct drm_i915_private *dev_priv, enum port port)
> >>  	return false;
> >>  }
> >>
> >> +bool intel_phy_is_tc(struct drm_i915_private *dev_priv, enum phy phy)
> >> +{
> >> +	if (INTEL_GEN(dev_priv) >= 11 && !IS_ELKHARTLAKE(dev_priv))
> >> +		return phy >= PHY_C && phy <= PHY_F;
> >> +
> >> +	return false;
> >> +}
> >> +
> >> +enum phy intel_port_to_phy(struct drm_i915_private *i915, enum port port)
> >> +{
> >> +	if (IS_ELKHARTLAKE(i915) && port == PORT_D)
> >> +		return PHY_A;
> >> +
> >> +	return (enum phy)port;
> >> +}
> >> +
> >>  enum tc_port intel_port_to_tc(struct drm_i915_private *dev_priv, enum port port)
> >>  {
> >> -	if (!intel_port_is_tc(dev_priv, port))
> >> +	if (!intel_phy_is_tc(dev_priv, intel_port_to_phy(dev_priv, port)))
> >>  		return PORT_TC_NONE;
> >>
> >>  	return port - PORT_C;
> >> diff --git a/drivers/gpu/drm/i915/display/intel_display.h b/drivers/gpu/drm/i915/display/intel_display.h
> >> index d296556ed82e..d53285fb883f 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_display.h
> >> +++ b/drivers/gpu/drm/i915/display/intel_display.h
> >> @@ -228,6 +228,21 @@ struct intel_link_m_n {
> >>  	u32 link_n;
> >>  };
> >>
> >> +enum phy {
> >> +	PHY_NONE = -1,
> >> +
> >> +	PHY_A = 0,
> >> +	PHY_B,
> >> +	PHY_C,
> >> +	PHY_D,
> >> +	PHY_E,
> >> +	PHY_F,
> >> +
> >> +	I915_MAX_PHYS
> >> +};
> >
> >I was pondering if we could eventually do something like:
> >
> >enum phy {
> >	PHY_COMBO_A = 0,
> >	PHY_COMBO_B,
> >	...
> >
> >	PHY_TC_1,
> >	PHY_TC_2,
> >	...
> >};
> >
> >and probably also add encoder->phy so we can contain
> >that port<->phy mapping logic in the encoder init.
> >I think that should work more or less fine since I
> >don't think PHY_TC_1 needs to have any specific value.
> 
> that's not true. All TC registers are based off the TC phy number.

That's just a trivial (x)-TC1, so I stand by what I said.

> Hence all the conversion we do port_to_tc()... I'd like to remove that
> in future and just stuff the phy index in intel_digital_port, as we
> already do for other tc_phy_* fields (we could add a union there so each
> phy adds its own fields).
> 
> And I'd rather not do the single phy namespace - it doesn't
> play well with TGL and the combo/tc.

I think it would work just fine for that. A single namespace would allow
us to remove all the crazy port->PHY type mapping we have going on
currently. Probably the best alternative would be separate namespaces
for each type with a new enum to identify the type.

> 
> Lucas De Marchi
> 
> >
> >Unfortunaltey I don't have a great idea how to do the
> >same for the DDIs since there the number of combo DDIs
> >changes but we still need the PORT_TC1 (assuming we had
> >one) to be DDI_<last combo DDI> + 1. One random silly
> >idea was to decouple the enum port from the register
> >definitions by having just some kind of
> >encoder->port_index for those. But that doesn't feel
> >entirely great either.
> >
> >Anyways, something to think about in the future perhaps.
> >
> >Patch is
> >Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> >> +
> >> +#define phy_name(a) ((a) + 'A')
> >> +
> >>  #define for_each_pipe(__dev_priv, __p) \
> >>  	for ((__p) = 0; (__p) < INTEL_INFO(__dev_priv)->num_pipes; (__p)++)
> >>
> >> @@ -356,5 +371,6 @@ void lpt_disable_clkout_dp(struct drm_i915_private *dev_priv);
> >>  u32 intel_plane_fb_max_stride(struct drm_i915_private *dev_priv,
> >>  			      u32 pixel_format, u64 modifier);
> >>  bool intel_plane_can_remap(const struct intel_plane_state *plane_state);
> >> +enum phy intel_port_to_phy(struct drm_i915_private *i915, enum port port);
> >>
> >>  #endif
> >> diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> >> index 24c63ed45c6f..815c26c0b98c 100644
> >> --- a/drivers/gpu/drm/i915/intel_drv.h
> >> +++ b/drivers/gpu/drm/i915/intel_drv.h
> >> @@ -1493,7 +1493,9 @@ void intel_encoder_destroy(struct drm_encoder *encoder);
> >>  struct drm_display_mode *
> >>  intel_encoder_current_mode(struct intel_encoder *encoder);
> >>  bool intel_port_is_combophy(struct drm_i915_private *dev_priv, enum port port);
> >> +bool intel_phy_is_combo(struct drm_i915_private *dev_priv, enum phy phy);
> >>  bool intel_port_is_tc(struct drm_i915_private *dev_priv, enum port port);
> >> +bool intel_phy_is_tc(struct drm_i915_private *dev_priv, enum phy phy);
> >>  enum tc_port intel_port_to_tc(struct drm_i915_private *dev_priv,
> >>  			      enum port port);
> >>  int intel_get_pipe_from_crtc_id_ioctl(struct drm_device *dev, void *data,
> >> --
> >> 2.17.2
> >
> >-- 
> >Ville Syrjälä
> >Intel

-- 
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2019-07-04 15:09 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-03 23:37 [PATCH v4 0/5] EHL port programming Matt Roper
2019-07-03 23:37 ` [PATCH v4 1/5] drm/i915/gen11: Start distinguishing 'phy' from 'port' Matt Roper
2019-07-04  9:18   ` Ville Syrjälä
2019-07-04  9:24     ` Ville Syrjälä
2019-07-04 14:54     ` Lucas De Marchi
2019-07-04 15:09       ` Ville Syrjälä [this message]
2019-07-04 15:55         ` Lucas De Marchi
2019-07-05 10:33           ` Ville Syrjälä
2019-07-08 14:02             ` Lucas De Marchi
2019-07-08 14:12               ` Ville Syrjälä
2019-07-08 23:59   ` Souza, Jose
2019-07-09  0:45     ` Souza, Jose
2019-07-03 23:37 ` [PATCH v4 2/5] drm/i915/gen11: Program DPCLKA_CFGCR0_ICL according to PHY Matt Roper
2019-07-04  1:06   ` [PATCH v5 " Matt Roper
2019-07-04  9:31     ` Ville Syrjälä
2019-07-09  0:15     ` Souza, Jose
2019-07-03 23:37 ` [PATCH v4 3/5] drm/i915/gen11: Convert combo PHY logic to use new 'enum phy' namespace Matt Roper
2019-07-04  9:39   ` Ville Syrjälä
2019-07-09  0:41   ` Souza, Jose
2019-07-03 23:37 ` [PATCH v4 4/5] drm/i915: Transition port type checks to phy checks Matt Roper
2019-07-04  0:02   ` [PATCH v5 " Matt Roper
2019-07-08 13:13     ` Ville Syrjälä
2019-07-04 16:07   ` [PATCH v4 " kbuild test robot
2019-07-09  1:00   ` Souza, Jose
2019-07-03 23:37 ` [PATCH v4 5/5] drm/i915/ehl: Enable DDI-D Matt Roper
2019-07-03 23:51 ` ✗ Fi.CI.BAT: failure for EHL port programming (rev4) Patchwork
2019-07-03 23:56 ` [PATCH v4 0/5] EHL port programming Souza, Jose
2019-07-04  0:40 ` ✗ Fi.CI.CHECKPATCH: warning for EHL port programming (rev5) Patchwork
2019-07-04  0:43 ` ✗ Fi.CI.SPARSE: " Patchwork
2019-07-04  1:18 ` ✓ Fi.CI.BAT: success " Patchwork
2019-07-04  1:55 ` ✗ Fi.CI.CHECKPATCH: warning for EHL port programming (rev6) Patchwork
2019-07-04  2:16 ` ✓ Fi.CI.BAT: success " Patchwork
2019-07-05  6:44 ` ✓ Fi.CI.IGT: " Patchwork

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=20190704150904.GI5942@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@intel.com \
    --cc=lucas.demarchi@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.