All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Sasha Finkelstein" <k@chaosmail.tech>
Cc: linux-phy@lists.infradead.org, devicetree@vger.kernel.org,
	robh@kernel.org, conor+dt@kernel.org, vkoul@kernel.org,
	neil.armstrong@linaro.org, olteanv@gmail.com
Subject: Re: [PATCH 4/4] phy: apple: atc: Add T8122 DisplayPort support
Date: Sun, 08 Nov 2026 16:03:01 +0000	[thread overview]
Message-ID: <sashiko-outbox-203869@kernel.org> (raw)
In-Reply-To: <20261108-t8122-phy-v1-4-c2783b2a53a8@chaosmail.tech>

Thank you for your contribution! Sashiko AI review found 2 potential
issues to consider:
- [Medium] phy: apple: atc: incomplete PHY reconfiguration on
  orientation change in atcphy_sw_set()
- [Medium] phy: apple: atc: missing RCAL1 poll for APPLE_ATCPHY_MODE_DP
  in atcphy_configure()
--

commit d63ba778ecb86e9dbceea7ed869d115d4530f29a
Author: Ramzi Abdiche <abdicheramzi@gmail.com>

phy: apple: atc: Add T8122 DisplayPort support

This commit adds DisplayPort AUX and lane configuration support for T8122
PHYs, introduces a DisplayPort operations table in struct atcphy_hw, and
stops active DisplayPort lanes before changing orientation or PHY mode.

> diff --git a/drivers/phy/apple/atc.c b/drivers/phy/apple/atc.c
> index 256a084996469..068d985b62a6d 100644
> --- a/drivers/phy/apple/atc.c
> +++ b/drivers/phy/apple/atc.c

[ ... ]

> @@ -1942,12 +2492,24 @@ static void atcphy_configure_post_tunable_t8122(struct apple_atcphy *atcphy, enu
>  	udelay(10);
>  }
>  
> +static void atcphy_configure_post_tunable_t8122(struct apple_atcphy *atcphy, enum atcphy_mode mode)
> +{
> +	if (atcphy_modes[mode].pipehandler_state == ATCPHY_PIPEHANDLER_STATE_USB3 ||
> +	    (atcphy->hw->dp && atcphy_modes[mode].enable_dp_aux))
> +		atcphy_power_on_common_t8122(atcphy);
> +}
> +
>  static int atcphy_configure(struct apple_atcphy *atcphy, enum atcphy_mode mode)
>  {
>  	int ret = 0;
>  	u32 reg;
>  
>  	lockdep_assert_held(&atcphy->lock);
> +	if (atcphy->hw->dp && atcphy->hw->dp->stop) {
> +		ret = atcphy->hw->dp->stop(atcphy);
> +		if (ret)
> +			return ret;
> +	}

[Severity: Medium]
Should the AUS_COMMON_DIG_RCAL1 poll later in atcphy_configure() also run
when (atcphy->hw->dp && atcphy_modes[mode].enable_dp_aux) is true?

atcphy_configure_post_tunable_t8122() now powers on the common block for
APPLE_ATCPHY_MODE_DP (where pipehandler_state is
ATCPHY_PIPEHANDLER_STATE_DUMMY), but atcphy_configure() only waits for
AUS_COMMON_DIG_RCAL1_ALL_CODES_DONE when pipehandler_state is
ATCPHY_PIPEHANDLER_STATE_USB3:

drivers/phy/apple/atc.c:atcphy_configure() {
    ...
	if (atcphy->hw->gen == ATCPHY_GENERATION_T8122 &&
	    atcphy_modes[mode].pipehandler_state == ATCPHY_PIPEHANDLER_STATE_USB3) {
		ret = readl_poll_timeout(atcphy->regs.core + AUS_COMMON_DIG_RCAL1, reg,
					 (reg & AUS_COMMON_DIG_RCAL1_ALL_CODES_DONE), 10, 100000);
    ...
}

In 4-lane DisplayPort mode (Pin Assignments C and E), the PHY will proceed
with AUX and link training without waiting for resistor calibration to
finish.

[ ... ]

> @@ -2257,19 +2829,31 @@ static int atcphy_probe_rcdev(struct apple_atcphy *atcphy)
>  static int atcphy_sw_set(struct typec_switch_dev *sw, enum typec_orientation orientation)
>  {
>  	struct apple_atcphy *atcphy = typec_switch_get_drvdata(sw);
> +	bool swap_lanes;
> +	int ret;
>  
>  	guard(mutex)(&atcphy->lock);
>  
>  	switch (orientation) {
>  	case TYPEC_ORIENTATION_NONE:
> -		break;
> +		return 0;
>  	case TYPEC_ORIENTATION_NORMAL:
> -		atcphy->swap_lanes = false;
> +		swap_lanes = false;
>  		break;
>  	case TYPEC_ORIENTATION_REVERSE:
> -		atcphy->swap_lanes = true;
> +		swap_lanes = true;
>  		break;
> +	default:
> +		return -EINVAL;
> +	}
> +
> +	/* Cleanup needs the old lane configuration until shutdown succeeds. */
> +	if (swap_lanes != atcphy->swap_lanes && atcphy->hw->dp && atcphy->hw->dp->stop) {
> +		ret = atcphy->hw->dp->stop(atcphy);
> +		if (ret)
> +			return ret;
>  	}
> +	atcphy->swap_lanes = swap_lanes;
>  
>  	return 0;
>  }

[Severity: Medium]
If orientation changes while atcphy->mode != APPLE_ATCPHY_MODE_OFF, does
stopping only the DisplayPort link leave the crossbar, lane mode, and
tunable registers programmed for the old orientation?

When atcphy_sw_set() flips atcphy->swap_lanes while a mode is already
active (the case where dp->stop() here has an effect, since transitioning
through TYPEC_STATE_SAFE already calls dp->stop() in atcphy_configure()),
atcphy->mode is left unchanged.  A subsequent atcphy_mux_set() for the
same mode returns early because atcphy->mode == target_mode, and
atcphy_dp_set_rate_t8122() then configures the DisplayPort PMA lanes for
the new swap_lanes while ACIOPHY_CROSSBAR, ACIOPHY_LANE_MODE, and
ATCPHY_MISC_LANE_SWAP remain set for the previous orientation.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261108-t8122-phy-v1-0-c2783b2a53a8@chaosmail.tech?part=4

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

WARNING: multiple messages have this Message-ID (diff)
From: sashiko-bot@kernel.org
To: "Sasha Finkelstein" <k@chaosmail.tech>
Cc: linux-phy@lists.infradead.org, devicetree@vger.kernel.org,
	robh@kernel.org, conor+dt@kernel.org, vkoul@kernel.org,
	neil.armstrong@linaro.org, olteanv@gmail.com
Subject: Re: [PATCH 4/4] phy: apple: atc: Add T8122 DisplayPort support
Date: Sun, 08 Nov 2026 16:03:01 +0000	[thread overview]
Message-ID: <sashiko-outbox-203869@kernel.org> (raw)
In-Reply-To: <20261108-t8122-phy-v1-4-c2783b2a53a8@chaosmail.tech>

Thank you for your contribution! Sashiko AI review found 2 potential
issues to consider:
- [Medium] phy: apple: atc: incomplete PHY reconfiguration on
  orientation change in atcphy_sw_set()
- [Medium] phy: apple: atc: missing RCAL1 poll for APPLE_ATCPHY_MODE_DP
  in atcphy_configure()
--

commit d63ba778ecb86e9dbceea7ed869d115d4530f29a
Author: Ramzi Abdiche <abdicheramzi@gmail.com>

phy: apple: atc: Add T8122 DisplayPort support

This commit adds DisplayPort AUX and lane configuration support for T8122
PHYs, introduces a DisplayPort operations table in struct atcphy_hw, and
stops active DisplayPort lanes before changing orientation or PHY mode.

> diff --git a/drivers/phy/apple/atc.c b/drivers/phy/apple/atc.c
> index 256a084996469..068d985b62a6d 100644
> --- a/drivers/phy/apple/atc.c
> +++ b/drivers/phy/apple/atc.c

[ ... ]

> @@ -1942,12 +2492,24 @@ static void atcphy_configure_post_tunable_t8122(struct apple_atcphy *atcphy, enu
>  	udelay(10);
>  }
>  
> +static void atcphy_configure_post_tunable_t8122(struct apple_atcphy *atcphy, enum atcphy_mode mode)
> +{
> +	if (atcphy_modes[mode].pipehandler_state == ATCPHY_PIPEHANDLER_STATE_USB3 ||
> +	    (atcphy->hw->dp && atcphy_modes[mode].enable_dp_aux))
> +		atcphy_power_on_common_t8122(atcphy);
> +}
> +
>  static int atcphy_configure(struct apple_atcphy *atcphy, enum atcphy_mode mode)
>  {
>  	int ret = 0;
>  	u32 reg;
>  
>  	lockdep_assert_held(&atcphy->lock);
> +	if (atcphy->hw->dp && atcphy->hw->dp->stop) {
> +		ret = atcphy->hw->dp->stop(atcphy);
> +		if (ret)
> +			return ret;
> +	}

[Severity: Medium]
Should the AUS_COMMON_DIG_RCAL1 poll later in atcphy_configure() also run
when (atcphy->hw->dp && atcphy_modes[mode].enable_dp_aux) is true?

atcphy_configure_post_tunable_t8122() now powers on the common block for
APPLE_ATCPHY_MODE_DP (where pipehandler_state is
ATCPHY_PIPEHANDLER_STATE_DUMMY), but atcphy_configure() only waits for
AUS_COMMON_DIG_RCAL1_ALL_CODES_DONE when pipehandler_state is
ATCPHY_PIPEHANDLER_STATE_USB3:

drivers/phy/apple/atc.c:atcphy_configure() {
    ...
	if (atcphy->hw->gen == ATCPHY_GENERATION_T8122 &&
	    atcphy_modes[mode].pipehandler_state == ATCPHY_PIPEHANDLER_STATE_USB3) {
		ret = readl_poll_timeout(atcphy->regs.core + AUS_COMMON_DIG_RCAL1, reg,
					 (reg & AUS_COMMON_DIG_RCAL1_ALL_CODES_DONE), 10, 100000);
    ...
}

In 4-lane DisplayPort mode (Pin Assignments C and E), the PHY will proceed
with AUX and link training without waiting for resistor calibration to
finish.

[ ... ]

> @@ -2257,19 +2829,31 @@ static int atcphy_probe_rcdev(struct apple_atcphy *atcphy)
>  static int atcphy_sw_set(struct typec_switch_dev *sw, enum typec_orientation orientation)
>  {
>  	struct apple_atcphy *atcphy = typec_switch_get_drvdata(sw);
> +	bool swap_lanes;
> +	int ret;
>  
>  	guard(mutex)(&atcphy->lock);
>  
>  	switch (orientation) {
>  	case TYPEC_ORIENTATION_NONE:
> -		break;
> +		return 0;
>  	case TYPEC_ORIENTATION_NORMAL:
> -		atcphy->swap_lanes = false;
> +		swap_lanes = false;
>  		break;
>  	case TYPEC_ORIENTATION_REVERSE:
> -		atcphy->swap_lanes = true;
> +		swap_lanes = true;
>  		break;
> +	default:
> +		return -EINVAL;
> +	}
> +
> +	/* Cleanup needs the old lane configuration until shutdown succeeds. */
> +	if (swap_lanes != atcphy->swap_lanes && atcphy->hw->dp && atcphy->hw->dp->stop) {
> +		ret = atcphy->hw->dp->stop(atcphy);
> +		if (ret)
> +			return ret;
>  	}
> +	atcphy->swap_lanes = swap_lanes;
>  
>  	return 0;
>  }

[Severity: Medium]
If orientation changes while atcphy->mode != APPLE_ATCPHY_MODE_OFF, does
stopping only the DisplayPort link leave the crossbar, lane mode, and
tunable registers programmed for the old orientation?

When atcphy_sw_set() flips atcphy->swap_lanes while a mode is already
active (the case where dp->stop() here has an effect, since transitioning
through TYPEC_STATE_SAFE already calls dp->stop() in atcphy_configure()),
atcphy->mode is left unchanged.  A subsequent atcphy_mux_set() for the
same mode returns early because atcphy->mode == target_mode, and
atcphy_dp_set_rate_t8122() then configures the DisplayPort PMA lanes for
the new swap_lanes while ACIOPHY_CROSSBAR, ACIOPHY_LANE_MODE, and
ATCPHY_MISC_LANE_SWAP remain set for the previous orientation.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261108-t8122-phy-v1-0-c2783b2a53a8@chaosmail.tech?part=4

  reply	other threads:[~2026-11-08 16:03 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-08 15:43 [PATCH 0/4] phy: apple: atc: Add M3 support Sasha Finkelstein
2026-11-08 15:43 ` Sasha Finkelstein
2026-11-08 15:43 ` [PATCH 1/4] dt-bindings: phy: atcphy: Add M3 series Sasha Finkelstein
2026-11-08 15:43   ` Sasha Finkelstein
2026-11-12 11:20   ` Krzysztof Kozlowski
2026-11-12 11:20     ` Krzysztof Kozlowski
2026-11-08 15:43 ` [PATCH 2/4] soc: apple: tunable: Allow passing NULL to tunable_apply Sasha Finkelstein
2026-11-08 15:43   ` Sasha Finkelstein
2026-11-08 15:48   ` Sven Peter
2026-11-08 15:48     ` Sven Peter
2026-11-08 15:43 ` [PATCH 3/4] phy: apple: atc: Add initial M3 series support Sasha Finkelstein
2026-11-08 15:43   ` Sasha Finkelstein
2026-11-08 15:56   ` sashiko-bot
2026-11-08 15:56     ` sashiko-bot
2026-11-08 18:15   ` Sven Peter
2026-11-08 18:15     ` Sven Peter
2026-11-08 18:17   ` Sven Peter
2026-11-08 18:17     ` Sven Peter
2026-11-08 18:21     ` Sasha Finkelstein
2026-11-08 18:21       ` Sasha Finkelstein
2026-11-08 18:25       ` Sven Peter
2026-11-08 18:25         ` Sven Peter
2026-11-08 23:32   ` kernel test robot
2026-11-08 23:32     ` kernel test robot
2026-11-08 15:43 ` [PATCH 4/4] phy: apple: atc: Add T8122 DisplayPort support Sasha Finkelstein
2026-11-08 15:43   ` Sasha Finkelstein
2026-11-08 16:03   ` sashiko-bot [this message]
2026-11-08 16:03     ` sashiko-bot

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=sashiko-outbox-203869@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=k@chaosmail.tech \
    --cc=linux-phy@lists.infradead.org \
    --cc=neil.armstrong@linaro.org \
    --cc=olteanv@gmail.com \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=vkoul@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.