public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: "Souza, Jose" <jose.souza@intel.com>
To: "ville.syrjala@linux.intel.com" <ville.syrjala@linux.intel.com>
Cc: "intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"Zanoni, Paulo R" <paulo.r.zanoni@intel.com>
Subject: Re: [PATCH 06/10] drm/i915/icl: Mark TC port as safe when interruptions are disabled
Date: Wed, 10 Oct 2018 18:27:07 +0000	[thread overview]
Message-ID: <734a7d5c7bef00266c04563378f383706edadb2d.camel@intel.com> (raw)
In-Reply-To: <20181010175209.GR9144@intel.com>

On Wed, 2018-10-10 at 20:52 +0300, Ville Syrjälä wrote:
> On Wed, Oct 10, 2018 at 05:23:30PM +0000, Souza, Jose wrote:
> > On Wed, 2018-10-10 at 20:15 +0300, Ville Syrjälä wrote:
> > > On Wed, Oct 10, 2018 at 12:55:07AM +0000, Souza, Jose wrote:
> > > > On Tue, 2018-10-02 at 23:35 +0300, Ville Syrjälä wrote:
> > > > > On Tue, Oct 02, 2018 at 10:50:50AM -0700, José Roberto de
> > > > > Souza
> > > > > wrote:
> > > > > > Before enter in power saving states or before unload the
> > > > > > driver
> > > > > > spec states that display driver is required to to mark TC
> > > > > > ports
> > > > > > as
> > > > > > safe so hardware can do the disconnection flow without wait
> > > > > > for
> > > > > > display driver handshake.
> > > > > > When driver is resumed or loaded again, if the TC live
> > > > > > state is
> > > > > > still set as connected driver will mark again TC port as
> > > > > > not
> > > > > > safe
> > > > > > as
> > > > > > required by spec.
> > > > > > 
> > > > > > BSpec: 2175
> > > > > > 
> > > > > > Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
> > > > > > Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
> > > > > > ---
> > > > > >  drivers/gpu/drm/i915/i915_irq.c | 10 ++++++++++
> > > > > >  1 file changed, 10 insertions(+)
> > > > > > 
> > > > > > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > > > > > b/drivers/gpu/drm/i915/i915_irq.c
> > > > > > index 2e242270e270..58616690f45f 100644
> > > > > > --- a/drivers/gpu/drm/i915/i915_irq.c
> > > > > > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > > > > > @@ -3640,6 +3640,7 @@ static void gen11_irq_reset(struct
> > > > > > drm_device
> > > > > > *dev)
> > > > > >  {
> > > > > >  	struct drm_i915_private *dev_priv = dev->dev_private;
> > > > > >  	int pipe;
> > > > > > +	u32 val;
> > > > > >  
> > > > > >  	I915_WRITE(GEN11_GFX_MSTR_IRQ, 0);
> > > > > >  	POSTING_READ(GEN11_GFX_MSTR_IRQ);
> > > > > > @@ -3661,6 +3662,15 @@ static void gen11_irq_reset(struct
> > > > > > drm_device *dev)
> > > > > >  
> > > > > >  	if (HAS_PCH_ICP(dev_priv))
> > > > > >  		GEN3_IRQ_RESET(SDE);
> > > > > > +
> > > > > > +	/*
> > > > > > +	 * Mark TC ports as safe so hardware can do the
> > > > > > disconnect flow
> > > > > > without
> > > > > > +	 * wait for driver to do the handshake
> > > > > > +	 */
> > > > > > +	val = I915_READ(PORT_TX_DFLEXDPCSSS);
> > > > > > +	for (pipe = 0; pipe < 4; pipe++)
> > > > > > +		val &= ~(DP_PHY_MODE_STATUS_NOT_SAFE(pipe));
> > > > > > +	I915_WRITE(PORT_TX_DFLEXDPCSSS, val);
> > > > > 
> > > > > Why would we have to do this here? The driver should
> > > > > relinquish
> > > > > control
> > > > > if and when it has shut down the pipes etc. Sounds like a bug
> > > > > if
> > > > > we're
> > > > > hanging on when we have no need for the port.
> > > > 
> > > > Right now we take control and only release it when port is
> > > > disconnected.
> > > 
> > > Disconnection is totally asynchronous. Someone could be using the
> > > port/aux for anything when the disconnect irq happens. Presumably
> > > bad things will happen if we just go and yank the control away
> > > when someone is doing stuff. I believe even the spec tells us
> > > to properly shut things down during the disconnect flow and make
> > > sure eg. the aux power wells have been fully shut down before
> > > relinquishing control.
> > 
> > In my understanding at the point of the gen11_irq_reset() call all
> > DDI
> > DDI ports and aux channels are already off.
> 
> I'm not talking about gen11_irq_reset(). But if we are then that gets
> called during driver load too and everything could be up and running.
> Though I'm not sure what the BIOS/GOP will do w.r.t. the safe mode
> knob.

BIOS should do the same connection flow to use sinks in tc ports.

> 
> Anyways, I don't think poking at some display stuff from irq_reset()
> is a particularly clean apporoach. The irq code should only concern

Move it to a function? Or move everything reseting display irq to a
function like is done for gen11_gt_irq_reset().

> itself with irqs. If we properly track which mode the port is in then
> I presume we'd just put it back into the tbt mode when the last
> typec mode user goes away. Or if we try to keep it in typec mode even
> when there are no users (as some kind of optimimization perhaps?)
> then
> we should probably switch it back to tbt mode during some display
> suspend/shutdown sequence.

We don't control what mode the connector is in, HW is the one that tell
us if it is in: type-c, TBT, legacy or disconnected state our only job
is grab and release this knob.

> 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2018-10-10 18:28 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-02 17:50 [PATCH 01/10] drm: Do not call drm_dp_cec_set_edid() while registering DP connectors José Roberto de Souza
2018-10-02 17:50 ` [PATCH 02/10] drm/i915: Make intel_dp_detect() more clear to read José Roberto de Souza
2018-10-03  7:25   ` Jani Nikula
2018-10-02 17:50 ` [PATCH 03/10] drm/i915: Do not get aux power for disconnected DP ports José Roberto de Souza
2018-10-02 20:04   ` Ville Syrjälä
2018-10-02 20:49   ` Ville Syrjälä
2018-10-02 17:50 ` [PATCH 04/10] drm/i915/debugfs: Do not print cached information of a disconnected sink José Roberto de Souza
2018-10-02 17:50 ` [PATCH 05/10] drm/i915: Do not try to set DPMS if sink is disconnected José Roberto de Souza
2018-10-02 20:32   ` Ville Syrjälä
2018-10-02 17:50 ` [PATCH 06/10] drm/i915/icl: Mark TC port as safe when interruptions are disabled José Roberto de Souza
2018-10-02 20:35   ` Ville Syrjälä
2018-10-10  0:55     ` Souza, Jose
2018-10-10 17:15       ` Ville Syrjälä
2018-10-10 17:23         ` Souza, Jose
2018-10-10 17:52           ` Ville Syrjälä
2018-10-10 18:27             ` Souza, Jose [this message]
2018-10-10 18:38               ` Ville Syrjälä
2018-10-02 17:50 ` [PATCH 07/10] drm/i915/icl: Set TC type to unknown in the disconnection flow José Roberto de Souza
2018-10-02 17:50 ` [PATCH 08/10] drm/i915/icl: Set TC type to unknown when a sudden disconnection happen José Roberto de Souza
2018-10-02 17:50 ` [PATCH 09/10] drm/i915: Initialize panel_vdd_work only for eDP ports José Roberto de Souza
2018-10-02 17:50 ` [PATCH 10/10] drm/i915/icl: Delay hotplug processing for tc ports José Roberto de Souza
2018-10-02 18:10 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/10] drm: Do not call drm_dp_cec_set_edid() while registering DP connectors Patchwork
2018-10-02 18:12 ` ✗ Fi.CI.SPARSE: " Patchwork
2018-10-02 18:33 ` ✓ Fi.CI.BAT: success " Patchwork
2018-10-03  8:32 ` ✗ Fi.CI.IGT: failure " 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=734a7d5c7bef00266c04563378f383706edadb2d.camel@intel.com \
    --to=jose.souza@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=paulo.r.zanoni@intel.com \
    --cc=ville.syrjala@linux.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