From: Johan Hovold <johan@kernel.org>
To: Qiang Yu <quic_qianyu@quicinc.com>
Cc: Johan Hovold <johan+linaro@kernel.org>,
Vinod Koul <vkoul@kernel.org>,
Kishon Vijay Abraham I <kishon@kernel.org>,
Dmitry Baryshkov <lumag@kernel.org>,
Neil Armstrong <neil.armstrong@linaro.org>,
Abel Vesa <abel.vesa@linaro.org>,
Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>,
linux-arm-msm@vger.kernel.org, linux-phy@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] phy: qcom: qmp-pcie: drop bogus x1e80100 qref supply
Date: Tue, 29 Apr 2025 10:47:45 +0200 [thread overview]
Message-ID: <aBCSMaZ7_tl-dEkB@hovoldconsulting.com> (raw)
In-Reply-To: <f44722a5-25b5-409c-baec-13d19af61d43@quicinc.com>
On Tue, Apr 29, 2025 at 04:24:19PM +0800, Qiang Yu wrote:
>
> On 4/29/2025 3:54 PM, Johan Hovold wrote:
> > The PCIe PHYs on x1e80100 do not a have a qref supply so stop requesting
> > one. This also avoids the follow warning at boot:
> >
> > qcom-qmp-pcie-phy 1be0000.phy: supply vdda-qref not found, using dummy regulator
> >
> > Fixes: e961ec81a39b ("phy: qcom: qmp: Add phy register and clk setting for x1e80100 PCIe3")
> > Cc: Qiang Yu <quic_qianyu@quicinc.com>
> > Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
> > ---
> We have QREF for each PCIe port on the X1E80100, all of which consume
> the regulator L3J. Although the PCIe PHY uses QREF indirectly, this
> creates a dependency, right?
The PHY binding should describe the direct dependencies for the PHY, so
the addition of qref for sm8550/sm8650 was probably also a mistake.
From what I could tell there is not even a one-to-one mapping of qref
supplies to PCIe ports, but perhaps you can provide more details on how
this fits together here?
> If PCIe doesn't vote for it, how can the
> PMIC driver decide when to disable L3J during system suspend or runtime
> suspend? Is there a chance that L3J could be disabled while PCIe still
> requires it?
If the QREF supplies can be turned off, you may need to mark them as
always-on until things are described properly. But whether that's needed
is not even clear at this point:
https://lore.kernel.org/lkml/17a1a4d9-fdc5-477a-bf4e-91cae5a62479@oss.qualcomm.com/
Johan
WARNING: multiple messages have this Message-ID (diff)
From: Johan Hovold <johan@kernel.org>
To: Qiang Yu <quic_qianyu@quicinc.com>
Cc: Johan Hovold <johan+linaro@kernel.org>,
Vinod Koul <vkoul@kernel.org>,
Kishon Vijay Abraham I <kishon@kernel.org>,
Dmitry Baryshkov <lumag@kernel.org>,
Neil Armstrong <neil.armstrong@linaro.org>,
Abel Vesa <abel.vesa@linaro.org>,
Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>,
linux-arm-msm@vger.kernel.org, linux-phy@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] phy: qcom: qmp-pcie: drop bogus x1e80100 qref supply
Date: Tue, 29 Apr 2025 10:47:45 +0200 [thread overview]
Message-ID: <aBCSMaZ7_tl-dEkB@hovoldconsulting.com> (raw)
In-Reply-To: <f44722a5-25b5-409c-baec-13d19af61d43@quicinc.com>
On Tue, Apr 29, 2025 at 04:24:19PM +0800, Qiang Yu wrote:
>
> On 4/29/2025 3:54 PM, Johan Hovold wrote:
> > The PCIe PHYs on x1e80100 do not a have a qref supply so stop requesting
> > one. This also avoids the follow warning at boot:
> >
> > qcom-qmp-pcie-phy 1be0000.phy: supply vdda-qref not found, using dummy regulator
> >
> > Fixes: e961ec81a39b ("phy: qcom: qmp: Add phy register and clk setting for x1e80100 PCIe3")
> > Cc: Qiang Yu <quic_qianyu@quicinc.com>
> > Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
> > ---
> We have QREF for each PCIe port on the X1E80100, all of which consume
> the regulator L3J. Although the PCIe PHY uses QREF indirectly, this
> creates a dependency, right?
The PHY binding should describe the direct dependencies for the PHY, so
the addition of qref for sm8550/sm8650 was probably also a mistake.
From what I could tell there is not even a one-to-one mapping of qref
supplies to PCIe ports, but perhaps you can provide more details on how
this fits together here?
> If PCIe doesn't vote for it, how can the
> PMIC driver decide when to disable L3J during system suspend or runtime
> suspend? Is there a chance that L3J could be disabled while PCIe still
> requires it?
If the QREF supplies can be turned off, you may need to mark them as
always-on until things are described properly. But whether that's needed
is not even clear at this point:
https://lore.kernel.org/lkml/17a1a4d9-fdc5-477a-bf4e-91cae5a62479@oss.qualcomm.com/
Johan
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
next prev parent reply other threads:[~2025-04-29 8:47 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-29 7:54 [PATCH] phy: qcom: qmp-pcie: drop bogus x1e80100 qref supply Johan Hovold
2025-04-29 7:54 ` Johan Hovold
2025-04-29 8:01 ` Abel Vesa
2025-04-29 8:01 ` Abel Vesa
2025-04-29 8:24 ` Qiang Yu
2025-04-29 8:24 ` Qiang Yu
2025-04-29 8:47 ` Johan Hovold [this message]
2025-04-29 8:47 ` Johan Hovold
2025-05-14 11:37 ` Vinod Koul
2025-05-14 11:37 ` Vinod Koul
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=aBCSMaZ7_tl-dEkB@hovoldconsulting.com \
--to=johan@kernel.org \
--cc=abel.vesa@linaro.org \
--cc=johan+linaro@kernel.org \
--cc=kishon@kernel.org \
--cc=konrad.dybcio@oss.qualcomm.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-phy@lists.infradead.org \
--cc=lumag@kernel.org \
--cc=neil.armstrong@linaro.org \
--cc=quic_qianyu@quicinc.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 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.