From: Robin Murphy <robin.murphy@arm.com>
To: Geraldo Nascimento <geraldogabriel@gmail.com>,
linux-rockchip@lists.infradead.org
Cc: "Shawn Lin" <shawn.lin@rock-chips.com>,
"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
"Krzysztof Wilczyński" <kw@linux.com>,
"Manivannan Sadhasivam" <mani@kernel.org>,
"Rob Herring" <robh@kernel.org>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Heiko Stuebner" <heiko@sntech.de>,
"Vinod Koul" <vkoul@kernel.org>,
"Kishon Vijay Abraham I" <kishon@kernel.org>,
"Rick wertenbroek" <rick.wertenbroek@gmail.com>,
linux-phy@lists.infradead.org, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v7 3/4] phy: rockchip-pcie: Enable all four lanes if required
Date: Mon, 30 Jun 2025 14:48:25 +0100 [thread overview]
Message-ID: <2affed16-f3c4-47d3-9ca6-e4f48e875367@arm.com> (raw)
In-Reply-To: <b203b067e369411b029039f96cfeae300874b4c7.1751200382.git.geraldogabriel@gmail.com>
On 29/06/2025 9:58 pm, Geraldo Nascimento wrote:
> Current code enables only Lane 0 because pwr_cnt will be incremented on
> first call to the function. Let's reorder the enablement code to enable
> all 4 lanes through GRF.
As usual the TRM isn't very clear, but the way it describes the
GRF_SOC_CON_5_PCIE bits does suggest they're driving external input
signals of the phy block, so it seems reasonable that it could be OK to
update the register itself without worrying about releasing the phy from
reset first. In that case I'd agree this seems the cleanest fix, and if
it works empirically then I think I'm now sufficiently convinced too;
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
> Signed-off-by: Geraldo Nascimento <geraldogabriel@gmail.com>
> ---
> drivers/phy/rockchip/phy-rockchip-pcie.c | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/phy/rockchip/phy-rockchip-pcie.c b/drivers/phy/rockchip/phy-rockchip-pcie.c
> index bd44af36c67a..f22ffb41cdc2 100644
> --- a/drivers/phy/rockchip/phy-rockchip-pcie.c
> +++ b/drivers/phy/rockchip/phy-rockchip-pcie.c
> @@ -160,6 +160,12 @@ static int rockchip_pcie_phy_power_on(struct phy *phy)
>
> guard(mutex)(&rk_phy->pcie_mutex);
>
> + regmap_write(rk_phy->reg_base,
> + rk_phy->phy_data->pcie_laneoff,
> + HIWORD_UPDATE(!PHY_LANE_IDLE_OFF,
> + PHY_LANE_IDLE_MASK,
> + PHY_LANE_IDLE_A_SHIFT + inst->index));
> +
> if (rk_phy->pwr_cnt++) {
> return 0;
> }
> @@ -176,12 +182,6 @@ static int rockchip_pcie_phy_power_on(struct phy *phy)
> PHY_CFG_ADDR_MASK,
> PHY_CFG_ADDR_SHIFT));
>
> - regmap_write(rk_phy->reg_base,
> - rk_phy->phy_data->pcie_laneoff,
> - HIWORD_UPDATE(!PHY_LANE_IDLE_OFF,
> - PHY_LANE_IDLE_MASK,
> - PHY_LANE_IDLE_A_SHIFT + inst->index));
> -
> /*
> * No documented timeout value for phy operation below,
> * so we make it large enough here. And we use loop-break
next prev parent reply other threads:[~2025-06-30 13:48 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-29 12:47 [PATCH v7 0/4] PCI: rockchip: Improve driver quality Geraldo Nascimento
2025-06-29 12:47 ` [PATCH v7 1/4] PCI: rockchip: Use standard PCIe defines Geraldo Nascimento
2025-06-29 12:48 ` [PATCH v7 2/4] PCI: rockchip: Set Target Link Speed before retraining Geraldo Nascimento
2025-06-29 12:48 ` [PATCH v7 4/4] phy: rockchip-pcie: Properly disable TEST_WRITE strobe signal Geraldo Nascimento
2025-06-30 8:49 ` neil.armstrong
2025-06-29 20:58 ` [PATCH v7 3/4] phy: rockchip-pcie: Enable all four lanes if required Geraldo Nascimento
2025-06-30 8:49 ` neil.armstrong
2025-06-30 13:48 ` Robin Murphy [this message]
2025-06-30 17:55 ` Geraldo Nascimento
2025-07-21 14:52 ` Geraldo Nascimento
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=2affed16-f3c4-47d3-9ca6-e4f48e875367@arm.com \
--to=robin.murphy@arm.com \
--cc=bhelgaas@google.com \
--cc=geraldogabriel@gmail.com \
--cc=heiko@sntech.de \
--cc=kishon@kernel.org \
--cc=kw@linux.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-phy@lists.infradead.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=lpieralisi@kernel.org \
--cc=mani@kernel.org \
--cc=rick.wertenbroek@gmail.com \
--cc=robh@kernel.org \
--cc=shawn.lin@rock-chips.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®