From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Imre Deak <imre.deak@intel.com>
Cc: intel-gfx@lists.freedesktop.org, stable@vger.kernel.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Fix AUX power domain toggling across TypeC mode resets
Date: Fri, 15 May 2020 20:30:54 +0300 [thread overview]
Message-ID: <20200515173054.GM6112@intel.com> (raw)
In-Reply-To: <20200515172445.GA20373@ideak-desk.fi.intel.com>
On Fri, May 15, 2020 at 08:24:45PM +0300, Imre Deak wrote:
> On Fri, May 15, 2020 at 07:21:06PM +0300, Ville Syrjälä wrote:
> > On Thu, May 14, 2020 at 11:45:53PM +0300, Imre Deak wrote:
> > > Make sure to select the port's AUX power domain while holding the TC
> > > port lock. The domain depends on the port's current TC mode, which may
> > > get changed under us if we're not holding the lock.
> >
> > Can we toss in a lockdep assert?
>
> Yes, can do that. However, now I realize, there is one more place to fix
> in intel_dp_force(), where I think we could just drop the aux get/put.
>
> So are you ok to do that as a follow-up?
Sure.
>
> > Did this by any chance help with the MST issues you were seeing?
>
> No, at least it didn't resolve it. Still some missing responses to MST
> down messages. More precisely the sink does send interrupts as a
> response, but the interrupt handler won't see the DP_DOWN_REP_MSG_RDY
> being set in ESI.
:(
>
> > > This was left out from
> > > commit 8c10e2262663 ("drm/i915: Keep the TypeC port mode fixed for detect/AUX transfers")
> > >
> > > Cc: <stable@vger.kernel.org> # v5.4+
> > > Signed-off-by: Imre Deak <imre.deak@intel.com>
> > > ---
> > > drivers/gpu/drm/i915/display/intel_dp.c | 5 +++--
> > > 1 file changed, 3 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
> > > index 408c3c1c5e81..40d42dcff0b7 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > > @@ -1359,8 +1359,7 @@ intel_dp_aux_xfer(struct intel_dp *intel_dp,
> > > bool is_tc_port = intel_phy_is_tc(i915, phy);
> > > i915_reg_t ch_ctl, ch_data[5];
> > > u32 aux_clock_divider;
> > > - enum intel_display_power_domain aux_domain =
> > > - intel_aux_power_domain(intel_dig_port);
> > > + enum intel_display_power_domain aux_domain;
> > > intel_wakeref_t aux_wakeref;
> > > intel_wakeref_t pps_wakeref;
> > > int i, ret, recv_bytes;
> > > @@ -1375,6 +1374,8 @@ intel_dp_aux_xfer(struct intel_dp *intel_dp,
> > > if (is_tc_port)
> > > intel_tc_port_lock(intel_dig_port);
> > >
> > > + aux_domain = intel_aux_power_domain(intel_dig_port);
> > > +
> > > aux_wakeref = intel_display_power_get(i915, aux_domain);
> > > pps_wakeref = pps_lock(intel_dp);
> > >
> > > --
> > > 2.23.1
> > >
> > > _______________________________________________
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >
> > --
> > 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
WARNING: multiple messages have this Message-ID (diff)
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Imre Deak <imre.deak@intel.com>
Cc: intel-gfx@lists.freedesktop.org, stable@vger.kernel.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Fix AUX power domain toggling across TypeC mode resets
Date: Fri, 15 May 2020 20:30:54 +0300 [thread overview]
Message-ID: <20200515173054.GM6112@intel.com> (raw)
In-Reply-To: <20200515172445.GA20373@ideak-desk.fi.intel.com>
On Fri, May 15, 2020 at 08:24:45PM +0300, Imre Deak wrote:
> On Fri, May 15, 2020 at 07:21:06PM +0300, Ville Syrjälä wrote:
> > On Thu, May 14, 2020 at 11:45:53PM +0300, Imre Deak wrote:
> > > Make sure to select the port's AUX power domain while holding the TC
> > > port lock. The domain depends on the port's current TC mode, which may
> > > get changed under us if we're not holding the lock.
> >
> > Can we toss in a lockdep assert?
>
> Yes, can do that. However, now I realize, there is one more place to fix
> in intel_dp_force(), where I think we could just drop the aux get/put.
>
> So are you ok to do that as a follow-up?
Sure.
>
> > Did this by any chance help with the MST issues you were seeing?
>
> No, at least it didn't resolve it. Still some missing responses to MST
> down messages. More precisely the sink does send interrupts as a
> response, but the interrupt handler won't see the DP_DOWN_REP_MSG_RDY
> being set in ESI.
:(
>
> > > This was left out from
> > > commit 8c10e2262663 ("drm/i915: Keep the TypeC port mode fixed for detect/AUX transfers")
> > >
> > > Cc: <stable@vger.kernel.org> # v5.4+
> > > Signed-off-by: Imre Deak <imre.deak@intel.com>
> > > ---
> > > drivers/gpu/drm/i915/display/intel_dp.c | 5 +++--
> > > 1 file changed, 3 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
> > > index 408c3c1c5e81..40d42dcff0b7 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > > @@ -1359,8 +1359,7 @@ intel_dp_aux_xfer(struct intel_dp *intel_dp,
> > > bool is_tc_port = intel_phy_is_tc(i915, phy);
> > > i915_reg_t ch_ctl, ch_data[5];
> > > u32 aux_clock_divider;
> > > - enum intel_display_power_domain aux_domain =
> > > - intel_aux_power_domain(intel_dig_port);
> > > + enum intel_display_power_domain aux_domain;
> > > intel_wakeref_t aux_wakeref;
> > > intel_wakeref_t pps_wakeref;
> > > int i, ret, recv_bytes;
> > > @@ -1375,6 +1374,8 @@ intel_dp_aux_xfer(struct intel_dp *intel_dp,
> > > if (is_tc_port)
> > > intel_tc_port_lock(intel_dig_port);
> > >
> > > + aux_domain = intel_aux_power_domain(intel_dig_port);
> > > +
> > > aux_wakeref = intel_display_power_get(i915, aux_domain);
> > > pps_wakeref = pps_lock(intel_dp);
> > >
> > > --
> > > 2.23.1
> > >
> > > _______________________________________________
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >
> > --
> > Ville Syrjälä
> > Intel
--
Ville Syrjälä
Intel
next prev parent reply other threads:[~2020-05-15 17:30 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-14 20:45 [Intel-gfx] [PATCH] drm/i915: Fix AUX power domain toggling across TypeC mode resets Imre Deak
2020-05-14 20:45 ` Imre Deak
2020-05-14 21:44 ` [Intel-gfx] " Souza, Jose
2020-05-14 21:44 ` Souza, Jose
2020-05-15 16:21 ` Ville Syrjälä
2020-05-15 16:21 ` Ville Syrjälä
2020-05-15 17:24 ` Imre Deak
2020-05-15 17:24 ` Imre Deak
2020-05-15 17:30 ` Ville Syrjälä [this message]
2020-05-15 17:30 ` Ville Syrjälä
2020-05-15 17:11 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
2020-05-15 17:36 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2020-05-15 20:36 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2020-05-19 11:32 ` Imre Deak
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=20200515173054.GM6112@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=imre.deak@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--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.