From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: "Souza, Jose" <jose.souza@intel.com>
Cc: "intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [PATCH 1/3] drm/i915/dp: Return the right vswing tables
Date: Tue, 31 Mar 2020 17:42:49 +0300 [thread overview]
Message-ID: <20200331144249.GP13686@intel.com> (raw)
In-Reply-To: <848c3ddd53f140bfe4f6e5a5d9c4bee544be9cf7.camel@intel.com>
On Mon, Mar 30, 2020 at 07:24:55PM +0000, Souza, Jose wrote:
> On Mon, 2020-03-30 at 17:50 +0300, Ville Syrjälä wrote:
> > On Fri, Mar 27, 2020 at 02:34:11PM -0700, José Roberto de Souza
> > wrote:
> > > DDI ports have its encoders initialized with INTEL_OUTPUT_DDI type
> > > and
> > > later eDP ports that have the type changed to INTEL_OUTPUT_EDP.
> > > But for all other DDI ports it can drive HDMI or DP depending on
> > > what
> > > user connects to the ports.
> > >
> > > ehl_get_combo_buf_trans() and tgl_get_combo_buf_trans() was
> > > checking
> > > for INTEL_OUTPUT_DP that was never true, causing eDP vswing tables
> > > being used.
> > >
> > > So here changing the check to INTEL_OUTPUT_DDI, HDMI cases will be
> > > correctly handled as it do not use encoder->type, instead it calls
> > > the
> > > functions with INTEL_OUTPUT_HDMI as type parameter and HDMI don't
> > > have
> > > retraining.
> > >
> > > Fixes: bd3cf6f7ce20 ("drm/i915/dp/tgl+: Update combo phy vswing
> > > tables")
> > > Cc: Clinton A Taylor <clinton.a.taylor@intel.com>
> > > Cc: Matt Roper <matthew.d.roper@intel.com>
> > > Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
> > > ---
> > > drivers/gpu/drm/i915/display/intel_ddi.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > > index 916a802af788..7af1572d4f1d 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > > @@ -947,7 +947,7 @@ static const struct cnl_ddi_buf_trans *
> > > ehl_get_combo_buf_trans(struct drm_i915_private *dev_priv, int
> > > type, int rate,
> > > int *n_entries)
> > > {
> > > - if (type == INTEL_OUTPUT_DP && rate > 270000) {
> > > + if (type == INTEL_OUTPUT_DDI && rate > 270000) {
> >
> > Please no. I'd rather not see "DDI" here. We want to check which mode
> > we're driving the output in, and "DDI" isn't one of the valid
> > choices.
> >
> > The fact that we sometimes pass in encoder->type is a bit of shortcut
> > to make the DP vs. EDP distinction. And so far every function knew to
> > only compare the value against EDP/HDMI and neve against DP. Looks
> > like
> > someone broke that (admittedly crappy) convention.
> >
> > We should probably fix this a bit higher up and make sure we only
> > ever
> > pass in EDP/DP/HDMI, never DDI.
>
> Okay so for now I will just do the bellow:
>
> if (type != INTEL_OUTPUT_EDP && type != INTEL_OUTPUT_HDMI && rate >
> 270000) {
>
> Good enough for now?
Works for me.
> >
> > > *n_entries =
> > > ARRAY_SIZE(ehl_combo_phy_ddi_translations_hbr2_hbr3);
> > > return ehl_combo_phy_ddi_translations_hbr2_hbr3;
> > > }
> > > @@ -959,7 +959,7 @@ static const struct cnl_ddi_buf_trans *
> > > tgl_get_combo_buf_trans(struct drm_i915_private *dev_priv, int
> > > type, int rate,
> > > int *n_entries)
> > > {
> > > - if (type != INTEL_OUTPUT_DP) {
> > > + if (type != INTEL_OUTPUT_DDI) {
> > > return icl_get_combo_buf_trans(dev_priv, type, rate,
> > > n_entries);
> > > } else if (rate > 270000) {
> > > *n_entries =
> > > ARRAY_SIZE(tgl_combo_phy_ddi_translations_dp_hbr2);
> > > --
> > > 2.26.0
> > >
> > > _______________________________________________
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
prev parent reply other threads:[~2020-03-31 14:42 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-27 21:34 [Intel-gfx] [PATCH 1/3] drm/i915/dp: Return the right vswing tables José Roberto de Souza
2020-03-27 21:34 ` [Intel-gfx] [PATCH 2/3] drm/i915/dp/ehl: Update vswing table for HBR and RBR José Roberto de Souza
2020-03-27 21:34 ` [Intel-gfx] [PATCH 3/3] drm/i915/tc/icl: Update TC vswing tables José Roberto de Souza
2020-03-27 22:24 ` [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915/dp: Return the right " Patchwork
2020-03-28 17:39 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2020-03-30 14:50 ` [Intel-gfx] [PATCH 1/3] " Ville Syrjälä
2020-03-30 19:24 ` Souza, Jose
2020-03-31 14:42 ` Ville Syrjälä [this message]
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=20200331144249.GP13686@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jose.souza@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.