From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: "Souza, Jose" <jose.souza@intel.com>
Cc: "De Marchi, Lucas" <lucas.demarchi@intel.com>,
"intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH v3 3/7] drm/i915: protect access to DP_TP_* on non-dp
Date: Wed, 4 Sep 2019 17:14:27 +0300 [thread overview]
Message-ID: <20190904141427.GC7482@intel.com> (raw)
In-Reply-To: <c57b342b3dd3567cc070660bbbe519b387f4431b.camel@intel.com>
On Wed, Sep 04, 2019 at 12:45:35AM +0000, Souza, Jose wrote:
> On Tue, 2019-09-03 at 10:16 -0700, Matt Roper wrote:
> > On Thu, Aug 29, 2019 at 01:37:55PM +0300, Ville Syrjälä wrote:
> > > On Thu, Aug 29, 2019 at 02:25:50AM -0700, Lucas De Marchi wrote:
> > > > DP_TP_{CTL,STATUS} should only be programmed when the encoder is
> > > > intel_dp.
> > > > Checking its current usages intel_disable_ddi_buf() is the only
> > > > offender, with other places being protected by checks like
> > > > pipe_config->fec_enable that is only set by intel_dp.
> > > >
> > > > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
> > > > ---
> > > > drivers/gpu/drm/i915/display/intel_ddi.c | 10 ++++++----
> > > > 1 file changed, 6 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > > > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > > > index 3180dacb5be4..df3e4fe7e3e9 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > > > @@ -3462,10 +3462,12 @@ static void intel_disable_ddi_buf(struct
> > > > intel_encoder *encoder,
> > > > wait = true;
> > > > }
> > > >
> > > > - val = I915_READ(DP_TP_CTL(port));
> > > > - val &= ~(DP_TP_CTL_ENABLE | DP_TP_CTL_LINK_TRAIN_MASK);
> > > > - val |= DP_TP_CTL_LINK_TRAIN_PAT1;
> > > > - I915_WRITE(DP_TP_CTL(port), val);
> > > > + if (intel_encoder_is_dp(encoder)) {
> > >
> > > Doesn't really make sense to me. Either we just do it (because a
> > > DDI is
> > > just a DDI so DP_TP_CTL does exist always), or we only do it when
> > > driving
> > > DP and not when driving HDMI.
> >
> > I agree; I don't think there's a need to avoid program programming
> > the
> > register just because we weren't previously in DP mode.
>
> The problem of always programing DP_TP_CTL comes with TGL, when
> DP_TP_CTL() moves to transcoder, see next patch: drm/i915/tgl: move
> DP_TP_* to transcoder.
>
> We are adding intel_dp->regs.dp_tp_ctl and initializing(this is
> necessary for MST for SST we could keep the current approach) it in DP
> paths, we could move it to intel_encoder or intel_digital_port and
> initialized it for HDMI too but it would not make any sense for someone
> reading HDMI sequences.
I'm not 100% sold on intel_dp->regs thing. Eventually I'd like to
remove all that crud from intel_dp and instead just plumb the crtc
state everywhere. But let's go with it for now.
Hmm. I just glanced at the modeset sequence in the spec, and it doesn't
touch DP_TP_CTL for HDMI, so I guess we might as well follow that same
sequence here and just go with intel_crtc_has_dp_encoder() instead
of intel_encoder_is_dp().
>
> And to move this to a DP specific function would force us to create
> another function to execute the last "wait DDI_BUF_CTL to idle".
>
> BSpec: 53339 and 22243
>
> Personally I prefer this patch solution but let me know your thoughts
> after this explanation.
>
> >
> > But I do question whether a RMW is necessary; it seems like just
> > writing
> > a constant 0 to this register would be sufficient for the disable
> > sequence.
> >
> >
> > Matt
> >
> > > For the latter I would perhaps suggest moving all this extra junk
> > > out
> > > from intel_disable_ddi_buf() into the DP specific code paths,
> > > leaving
> > > just the actual DDI_BUF_CTL disable here.
> > >
> > > > + val = I915_READ(DP_TP_CTL(port));
> > > > + val &= ~(DP_TP_CTL_ENABLE | DP_TP_CTL_LINK_TRAIN_MASK);
> > > > + val |= DP_TP_CTL_LINK_TRAIN_PAT1;
> > > > + I915_WRITE(DP_TP_CTL(port), val);
> > > > + }
> > > >
> > > > /* Disable FEC in DP Sink */
> > > > intel_ddi_disable_fec_state(encoder, crtc_state);
> > > > --
> > > > 2.23.0
> > >
> > > --
> > > 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
next prev parent reply other threads:[~2019-09-04 14:14 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-29 9:25 [PATCH v3 0/7] Tiger Lake batch 3.5 Lucas De Marchi
2019-08-29 9:25 ` [PATCH v3 1/7] drm/i915/psr: Only handle interruptions of the transcoder in use Lucas De Marchi
2019-09-03 21:42 ` Matt Roper
2019-09-03 21:53 ` Souza, Jose
2019-09-03 21:59 ` Matt Roper
2019-08-29 9:25 ` [PATCH v3 2/7] drm/i915/tgl: Access the right register when handling PSR interruptions Lucas De Marchi
2019-09-03 16:52 ` Matt Roper
2019-08-29 9:25 ` [PATCH v3 3/7] drm/i915: protect access to DP_TP_* on non-dp Lucas De Marchi
2019-08-29 10:37 ` Ville Syrjälä
2019-09-03 17:16 ` Matt Roper
2019-09-04 0:45 ` Souza, Jose
2019-09-04 14:14 ` Ville Syrjälä [this message]
2019-08-29 9:25 ` [PATCH v3 4/7] drm/i915/tgl: move DP_TP_* to transcoder Lucas De Marchi
2019-09-03 17:55 ` Matt Roper
2019-09-04 20:44 ` Souza, Jose
2019-09-04 21:04 ` Souza, Jose
2019-08-29 9:25 ` [PATCH v3 5/7] drm/i915/tgl: disable SAGV temporarily Lucas De Marchi
2019-08-30 20:01 ` Souza, Jose
2019-09-03 22:05 ` Matt Roper
2019-09-03 22:45 ` Souza, Jose
2019-08-29 9:25 ` [PATCH v3 6/7] drm/i915/tgl: add gen12 to stolen initialization Lucas De Marchi
2019-09-03 21:43 ` Souza, Jose
2019-09-03 22:10 ` Matt Roper
2019-08-29 9:25 ` [PATCH v3 7/7] FIXME: drm/i915/tgl: Register state context definition for Gen12 Lucas De Marchi
2019-08-29 9:59 ` ✗ Fi.CI.CHECKPATCH: warning for Tiger Lake batch 3.5 Patchwork
2019-08-29 12:18 ` ✓ Fi.CI.BAT: success " Patchwork
2019-08-29 15:08 ` [PATCH v3 0/7] " Daniele Ceraolo Spurio
2019-08-29 23:38 ` ✓ Fi.CI.IGT: success for " 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=20190904141427.GC7482@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jose.souza@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.