From: Krzysztof Kozlowski <krzk@kernel.org>
To: Qiang Yu <qiang.yu@oss.qualcomm.com>
Cc: Vinod Koul <vkoul@kernel.org>,
Neil Armstrong <neil.armstrong@linaro.org>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Philipp Zabel <p.zabel@pengutronix.de>,
Bjorn Andersson <andersson@kernel.org>,
Konrad Dybcio <konradybcio@kernel.org>,
linux-arm-msm@vger.kernel.org, linux-phy@lists.infradead.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 1/5] dt-bindings: phy: qcom,sc8280xp-qmp-pcie-phy: Add support for glymur Gen5 x8 bifurcation mode
Date: Mon, 20 Apr 2026 15:23:43 +0200 [thread overview]
Message-ID: <20260420-optimistic-unnatural-stingray-80da35@quoll> (raw)
In-Reply-To: <aeXUZ1uSEJ9InUtw@hu-qianyu-lv.qualcomm.com>
On Mon, Apr 20, 2026 at 12:23:19AM -0700, Qiang Yu wrote:
> On Fri, Apr 17, 2026 at 11:18:08AM +0200, Krzysztof Kozlowski wrote:
> > On Wed, Apr 15, 2026 at 07:58:13PM -0700, Qiang Yu wrote:
> > > On Wed, Apr 15, 2026 at 09:50:28AM +0200, Krzysztof Kozlowski wrote:
> > > > On Sun, Apr 12, 2026 at 11:25:56PM -0700, Qiang Yu wrote:
> > > > > The Glymur SoC has pcie3a and pcie3b PHYs that can operate in two modes:
> > > > >
> > > > > 1. Independent 4-lane mode: Each PHY operates as a separate PCIe Gen5
> > > > > 4-lane interface, compatible with qcom,glymur-qmp-gen5x4-pcie-phy
> > > > > 2. Bifurcation mode (8-lane): pcie3a phy acts as leader and pcie3b phy as
> > > > > follower to form a single 8-lane PCIe Gen5 interface
> > > > >
> > > > > In bifurcation mode, the hardware design requires controlling additional
> > > > > resources beyond the standard pcie3a PHY configuration:
> > > > >
> > > > > - pcie3b's aux_clk (phy_b_aux)
> > > > > - pcie3b's phy_gdsc power domain
> > > > > - pcie3b's bcr/nocsr reset
> > > > >
> > > > > Add qcom,glymur-qmp-gen5x8-pcie-phy compatible string to document this
> > > > > 8-lane bifurcation configuration.
> > > >
> > > > Do you describe PCI3A or PCI3B or something combined PCI3?
> > >
> > > I describe a single x8 PHY with resources from both the pcie3a and pcie3b
> > > PHY blocks for x8 operation.
> > >
> > > >
> > > > >
> > > > > The phy_b_aux clock is used as the 6th clock instead of pipediv2,
> > > > > requiring the clock-names enum to be extended to support both
> > > > > [phy_b_aux, pipediv2] options at index 5. This follows the existing
> > > > > pattern used for [rchng, refgen] clocks at index 3.
> > > > >
> > > > > Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> > > > > ---
> > > > > .../bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml | 53 ++++++++++++++++++----
> > > > > 1 file changed, 45 insertions(+), 8 deletions(-)
> > > > >
> > > > > diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
> > > > > index 3a35120a77ec0ceb814a1cdcacff32fef32b4f7b..14eba5d705b1956c1bb00cc8c95171ed6488299b 100644
> > > > > --- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
> > > > > +++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
> > > > > @@ -18,6 +18,7 @@ properties:
> > > > > enum:
> > > > > - qcom,glymur-qmp-gen4x2-pcie-phy
> > > > > - qcom,glymur-qmp-gen5x4-pcie-phy
> > > > > + - qcom,glymur-qmp-gen5x8-pcie-phy
> > > >
> > > > That's the same device as 5x4, no? One device, one compatible and this
> > > > suggests you will have three PCI phys in the DT - two 5x4 and one 5x8?
> > > >
> > >
> > > It is not the same as the 5x4 PHY. In DT, we model three PHY nodes:
> > > phy_3a (1x4), phy_3b (1x4), and a separate phy_1x8 node for x8 mode.
> >
> > OK, that's what I wanted to hear. And that's what should not be done,
> >
> > You should not have a separate node for the same hardware. First, DTC
> > will give you a W=1 warning, although warning itself should be moved to
> > W=2.
> >
> > Second, the warning tells important story - same hardware is described
> > twice.
> >
> > You only need phy_3a and phy_3b, so only two in total.
>
> We can keep only phy_3a and phy_3b, but still add new compatible
> qcom,glymur-qmp-gen5x8-pcie-phy in binding, right?
>
> For boards that support pcie3a(1x4) + pcie3b(1x4), DTS would be:
>
> pcie3a_phy { compatible = "qcom,glymur-qmp-gen5x4-pcie-phy"; };
> pcie3b_phy { compatible = "qcom,glymur-qmp-gen5x4-pcie-phy"; };
>
> For boards that support 1x8, we would override pcie3a_phy with:
>
> pcie3a_phy { compatible = "qcom,glymur-qmp-gen5x8-pcie-phy"; /* additional resources */ };
> pcie3b_phy { compatible = "qcom,glymur-qmp-gen5x4-pcie-phy"; };
>
> This still uses only two PHY nodes and DTC will not report warning.
IMO, you do not need another compatible. Device is exactly the same. If
wiring on the board differs, e.g. you have 8x instead of 4x, you:
1. disable unused 3B phy.
2. Add to 3A missing resources or the phandle to companion node.
At least that is what I tought till now, when I opened the HPG/manual
for Glymur phy. Someone skipped important information when PCIe PHY was
upstreamed first and glymur.dtsi already got PHY 3B described.
Reminder: writing bindings asks you explicitly to post COMPLETE
bindings.
If you posted COMPLETE bindings we would question all this and you would
have to check in user manual that this is actually ONE device.
There is no 5x4 phy 3A and 3B, at least HPG is pretty clear here.
And you should start with that.
But you posted first incomplete binding, hiding the rest and now you
have 5x4 merged into DTSI.
So let's rephrase based on manual:
You have only one PCIE phy3. Not 3A + 3B. That one phy3 can be
configured by consumers (board) differently, e.g. by requesting 8-lane
or twice 4-lane phys.
Let me send correction note for glymur.dtsi.
Best regards,
Krzysztof
next prev parent reply other threads:[~2026-04-20 13:23 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-13 6:25 [PATCH v3 0/5] phy: qcom: qmp-pcie: Add PCIe Gen5 8-lane bifurcation support for Glymur Qiang Yu
2026-04-13 6:25 ` [PATCH v3 1/5] dt-bindings: phy: qcom,sc8280xp-qmp-pcie-phy: Add support for glymur Gen5 x8 bifurcation mode Qiang Yu
2026-04-15 7:50 ` Krzysztof Kozlowski
2026-04-16 2:58 ` Qiang Yu
2026-04-17 9:18 ` Krzysztof Kozlowski
2026-04-20 7:23 ` Qiang Yu
2026-04-20 13:23 ` Krzysztof Kozlowski [this message]
2026-04-22 6:19 ` Qiang Yu
2026-04-22 6:27 ` Krzysztof Kozlowski
2026-04-22 6:27 ` Krzysztof Kozlowski
2026-04-23 6:29 ` Qiang Yu
2026-04-13 6:25 ` [PATCH v3 2/5] phy: qcom: qmp-pcie: Add multiple power-domains support Qiang Yu
2026-04-13 6:25 ` [PATCH v3 3/5] phy: qcom: qmp-pcie: Support multiple nocsr resets Qiang Yu
2026-04-13 8:10 ` Philipp Zabel
2026-04-16 3:02 ` Qiang Yu
2026-04-13 6:25 ` [PATCH v3 4/5] phy: qcom: qmp-pcie: Add Gen5 8-lanes mode for Glymur Qiang Yu
2026-04-13 6:26 ` [PATCH v3 5/5] arch: arm64: dts: qcom: Add support for PCIe3a Qiang Yu
2026-04-15 7:44 ` Krzysztof Kozlowski
2026-04-16 3:24 ` Qiang Yu
2026-04-16 6:19 ` Krzysztof Kozlowski
2026-04-20 7:30 ` Qiang Yu
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=20260420-optimistic-unnatural-stingray-80da35@quoll \
--to=krzk@kernel.org \
--cc=andersson@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=konradybcio@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-phy@lists.infradead.org \
--cc=neil.armstrong@linaro.org \
--cc=p.zabel@pengutronix.de \
--cc=qiang.yu@oss.qualcomm.com \
--cc=robh@kernel.org \
--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