intel-xe.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Luca Coelho <luca@coelho.fi>
To: imre.deak@intel.com, Jani Nikula <jani.nikula@linux.intel.com>,
	 intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
	 stable@vger.kernel.org, Charlton Lin <charlton.lin@intel.com>,
	Khaled Almahallawy <khaled.almahallawy@intel.com>
Subject: Re: [PATCH 01/19] drm/i915/lnl+/tc: Fix handling of an enabled/disconnected dp-alt sink
Date: Thu, 07 Aug 2025 17:10:11 +0300	[thread overview]
Message-ID: <1e1a3f0db25d4487a3b10522404ea004139ce8e7.camel@coelho.fi> (raw)
In-Reply-To: <aJShB9ufOBH9AWLY@ideak-desk>

On Thu, 2025-08-07 at 15:50 +0300, Imre Deak wrote:
> On Thu, Aug 07, 2025 at 03:33:04PM +0300, Imre Deak wrote:
> > On Thu, Aug 07, 2025 at 03:19:17PM +0300, Jani Nikula wrote:
> > > On Thu, 07 Aug 2025, Imre Deak <imre.deak@intel.com> wrote:
> > > > On Thu, Aug 07, 2025 at 01:59:21PM +0300, Luca Coelho wrote:
> > > > > On Tue, 2025-08-05 at 10:36 +0300, Imre Deak wrote:
> > > > > > The TypeC PHY HW readout during driver loading and system resume
> > > > > > determines which TypeC mode the PHY is in (legacy/DP-alt/TBT-alt) and
> > > > > > whether the PHY is connected, based on the PHY's Owned and Ready flags.
> > > > > > For the PHY to be in DP-alt or legacy mode and for the PHY to be in the
> > > > > > connected state in these modes, both the Owned (set by the BIOS/driver)
> > > > > > and the Ready (set by the HW) flags should be set.
> > > > > > 
> > > > > > On ICL-MTL the HW kept the PHY's Ready flag set after the driver
> > > > > > connected the PHY by acquiring the PHY ownership (by setting the Owned
> > > > > > flag), until the driver disconnected the PHY by releasing the PHY
> > > > > > ownership (by clearing the Owned flag). On LNL+ this has changed, in
> > > > > > that the HW clears the Ready flag as soon as the sink gets disconnected,
> > > > > > even if the PHY ownership was acquired already and hence the PHY is
> > > > > > being used by the display.
> > > > > > 
> > > > > > When inheriting the HW state from BIOS for a PHY connected in DP-alt
> > > > > > mode on which the sink got disconnected - i.e. in a case where the sink
> > > > > > was connected while BIOS/GOP was running and so the sink got enabled
> > > > > > connecting the PHY, but the user disconnected the sink by the time the
> > > > > > driver loaded - the PHY Owned but not Ready state must be accounted for
> > > > > > on LNL+ according to the above. Do that by assuming on LNL+ that the PHY
> > > > > > is connected in DP-alt mode whenever the PHY Owned flag is set,
> > > > > > regardless of the PHY Ready flag.
> > > > > > 
> > > > > > This fixes a problem on LNL+, where the PHY TypeC mode / connected state
> > > > > > was detected incorrectly for a DP-alt sink, which got connected and then
> > > > > > disconnected by the user in the above way.
> > > > > > 
> > > > > > Cc: stable@vger.kernel.org # v6.8+
> > > > > > Reported-by: Charlton Lin <charlton.lin@intel.com>
> > > > > > Tested-by: Khaled Almahallawy <khaled.almahallawy@intel.com>
> > > > > > Signed-off-by: Imre Deak <imre.deak@intel.com>
> > > > > > ---
> > > > > >  drivers/gpu/drm/i915/display/intel_tc.c | 16 ++++++++++------
> > > > > >  1 file changed, 10 insertions(+), 6 deletions(-)
> > > > > > 
> > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_tc.c b/drivers/gpu/drm/i915/display/intel_tc.c
> > > > > > index 3bc57579fe53e..73a08bd84a70a 100644
> > > > > > --- a/drivers/gpu/drm/i915/display/intel_tc.c
> > > > > > +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> > > > > > @@ -1226,14 +1226,18 @@ static void tc_phy_get_hw_state(struct intel_tc_port *tc)
> > > > > >  	tc->phy_ops->get_hw_state(tc);
> > > > > >  }
> > > > > >  
> > > > > > -static bool tc_phy_is_ready_and_owned(struct intel_tc_port *tc,
> > > > > > -				      bool phy_is_ready, bool phy_is_owned)
> > > > > > +static bool tc_phy_in_legacy_or_dp_alt_mode(struct intel_tc_port *tc,
> > > > > > +					    bool phy_is_ready, bool phy_is_owned)
> > > > > 
> > > > > Personally I don't like the "or" in the function name.  You're
> > > > > returning a boolean which is true or false.  The return value is akin
> > > > > to answering "Yes/No" to the question "Is it black or white".
> > > > 
> > > > The question the function is meant to answer is "Is the PHY in legacy or
> > > > DP-alt mode?". The return value is true (yes) if the PHY is in either
> > > > legacy or DP-alt mode, false (no) if the PHY is neither in legacy or
> > > > DP-alt mode. There are many other uses of "or" in function names in this
> > > > sense, so not sure how else I'd name this one. Simply leaving out "or"
> > > > would make it less clear that the legacy and DP-alt modes are two
> > > > separate modes.

Right, I missed that.  But one shouldn't have to go read the function
implementation to know what it's doing.


> > > 
> > > What's the opposite of "Is the PHY in legacy or DP-alt mode"?
> > > 
> > > Would that lead to a simpler name, with the reversed return value?
> > 
> > The opposite is either TBT-alt or disconnected mode, so the reversal
> > would result in the same function name format.
> 
> Would you be ok with
> 
> tc_phy_owned_by_display()
> 
> ?

This sounds much better! And it's indeed what you're looking for.  It
doesn't matter if it's legacy DP-alt, TBT-alt or whatever.  What you're
checking is actually whether display owns the PHY.  So this is a much
better choice IMHO. :)

--
Cheers,
Luca.

  parent reply	other threads:[~2025-08-07 14:10 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-05  7:36 [PATCH 00/19] drm/i915/tc: Fix enabled/disconnected DP-alt sink handling Imre Deak
2025-08-05  7:36 ` [PATCH 01/19] drm/i915/lnl+/tc: Fix handling of an enabled/disconnected dp-alt sink Imre Deak
2025-08-07  7:06   ` Kahola, Mika
2025-08-07 10:59   ` Luca Coelho
2025-08-07 11:38     ` Imre Deak
2025-08-07 12:19       ` Jani Nikula
2025-08-07 12:32         ` Imre Deak
2025-08-07 12:50           ` Imre Deak
2025-08-07 13:05             ` Jani Nikula
2025-08-07 13:24               ` Imre Deak
2025-08-07 14:10             ` Luca Coelho [this message]
2025-08-05  7:36 ` [PATCH 02/19] drm/i915/icl+/tc: Cache the max lane count value Imre Deak
2025-08-05  9:33   ` [PATCH v2 " Imre Deak
2025-08-07  8:07     ` Kahola, Mika
2025-08-05  7:36 ` [PATCH 03/19] drm/i915/lnl+/tc: Fix max lane count HW readout Imre Deak
2025-08-05  9:33   ` [PATCH v2 " Imre Deak
2025-08-07  8:36     ` Kahola, Mika
2025-08-05  7:36 ` [PATCH 04/19] drm/i915/lnl+/tc: Use the cached max lane count value Imre Deak
2025-08-07  8:49   ` Kahola, Mika
2025-08-05  7:36 ` [PATCH 05/19] drm/i915/icl+/tc: Convert AUX powered WARN to a debug message Imre Deak
2025-08-07 12:29   ` Kahola, Mika
2025-08-05  7:36 ` [PATCH 06/19] drm/i915/tc: Use the cached max lane count value Imre Deak
2025-08-06 12:02   ` Kahola, Mika
2025-08-05  7:36 ` [PATCH 07/19] drm/i915/tc: Move getting the power domain before reading DFLEX registers Imre Deak
2025-08-06 12:56   ` Kahola, Mika
2025-08-05  7:36 ` [PATCH 08/19] drm/i915/tc: Move asserting the power state after reading TCSS_DDI_STATUS Imre Deak
2025-08-06 13:22   ` Kahola, Mika
2025-08-05  7:36 ` [PATCH 09/19] drm/i915/tc: Add an enum for the TypeC pin assignment Imre Deak
2025-08-07 12:39   ` Kahola, Mika
2025-08-05  7:36 ` [PATCH 10/19] drm/i915/tc: Pass pin assignment value around using the pin assignment enum Imre Deak
2025-08-07 12:56   ` Kahola, Mika
2025-08-05  7:36 ` [PATCH 11/19] drm/i915/tc: Handle pin assignment NONE on all platforms Imre Deak
2025-08-07 12:57   ` Kahola, Mika
2025-08-05  7:36 ` [PATCH 12/19] drm/i915/tc: Validate the pin assignment " Imre Deak
2025-08-07 13:08   ` Kahola, Mika
2025-08-05  7:36 ` [PATCH 13/19] drm/i915/tc: Unify the way to get " Imre Deak
2025-08-08  6:44   ` Kahola, Mika
2025-08-05  7:36 ` [PATCH 14/19] drm/i915/tc: Unify the way to get the max lane count value on MTL+ Imre Deak
2025-08-08  7:32   ` Kahola, Mika
2025-08-05  7:36 ` [PATCH 15/19] drm/i915/tc: Handle non-TC encoders when getting the pin assignment Imre Deak
2025-08-08  7:45   ` Kahola, Mika
2025-08-05  7:36 ` [PATCH 16/19] drm/i915/tc: Pass intel_tc_port to internal lane mask/count helpers Imre Deak
2025-08-08  8:25   ` Kahola, Mika
2025-08-05  7:36 ` [PATCH 17/19] dmc/i915/tc: Report pin assignment NONE in TBT-alt mode Imre Deak
2025-08-08  8:26   ` Kahola, Mika
2025-08-05  7:36 ` [PATCH 18/19] drm/i915/tc: Cache the pin assignment value Imre Deak
2025-08-08  8:27   ` Kahola, Mika
2025-08-05  7:37 ` [PATCH 19/19] drm/i915/tc: Debug print the pin assignment and max lane count Imre Deak
2025-08-08  8:28   ` Kahola, Mika
2025-08-05  7:46 ` ✗ CI.checkpatch: warning for drm/i915/tc: Fix enabled/disconnected DP-alt sink handling Patchwork
2025-08-05  7:47 ` ✓ CI.KUnit: success " Patchwork
2025-08-05  8:02 ` ✗ CI.checksparse: warning " Patchwork
2025-08-05  8:49 ` ✗ Xe.CI.BAT: failure " Patchwork
2025-08-05 10:08 ` ✓ Xe.CI.Full: success " Patchwork
2025-08-05 11:41 ` ✗ CI.checkpatch: warning for drm/i915/tc: Fix enabled/disconnected DP-alt sink handling (rev3) Patchwork
2025-08-05 11:42 ` ✓ CI.KUnit: success " Patchwork
2025-08-05 11:57 ` ✗ CI.checksparse: warning " Patchwork
2025-08-05 13:02 ` ✓ Xe.CI.BAT: success " Patchwork
2025-08-05 15:31 ` ✓ Xe.CI.Full: " Patchwork
2025-08-06 11:44 ` [PATCH 00/19] drm/i915/tc: Fix enabled/disconnected DP-alt sink handling Luca Coelho
2025-08-06 11:54   ` Imre Deak
2025-08-06 12:54     ` Luca Coelho
2025-08-06 13:12       ` Imre Deak
2025-08-06 13:16         ` Luca Coelho
     [not found] ` <175439829105.213103.3969215907569188087@1538d3639d33>
2025-08-13 12:43   ` ✗ i915.CI.Full: failure for drm/i915/tc: Fix enabled/disconnected DP-alt sink handling (rev3) 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=1e1a3f0db25d4487a3b10522404ea004139ce8e7.camel@coelho.fi \
    --to=luca@coelho.fi \
    --cc=charlton.lin@intel.com \
    --cc=imre.deak@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=khaled.almahallawy@intel.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).