public inbox for devicetree@vger.kernel.org
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <krzk@kernel.org>
To: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Cc: Ziyue Zhang <quic_ziyuzhan@quicinc.com>,
	vkoul@kernel.org, kishon@kernel.org, dmitry.baryshkov@linaro.org,
	abel.vesa@linaro.org, neil.armstrong@linaro.org,
	andersson@kernel.org, konradybcio@kernel.org, robh@kernel.org,
	krzk+dt@kernel.org, conor+dt@kernel.org,
	linux-arm-msm@vger.kernel.org, linux-phy@lists.infradead.org,
	linux-kernel@vger.kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH 1/3] dt-bindings: phy: qcom,qmp-pcie: add optional current load properties
Date: Wed, 11 Dec 2024 09:09:18 +0100	[thread overview]
Message-ID: <33697bd9-02f4-4a9a-b8c0-4930d7fdaee2@kernel.org> (raw)
In-Reply-To: <20241211062053.vxdpovlmetvyx3za@thinkpad>

On 11/12/2024 07:20, Manivannan Sadhasivam wrote:
> On Thu, Dec 05, 2024 at 11:23:11AM +0100, Krzysztof Kozlowski wrote:
>> On Wed, Dec 04, 2024 at 06:52:47PM +0800, Ziyue Zhang wrote:
>>> On some platforms, the power supply for PCIe PHY is not able to provide
>>> enough current when it works in LPM mode. Hence, PCIe PHY driver needs to
>>> set current load to vote the regulator to HPM mode.
>>>
>>> Document the current load as properties for each power supply PCIe PHY
>>> required, namely vdda-phy-max-microamp, vdda-pll-max-microamp and
>>> vdda-qref-max-microamp, respectively.PCIe PHY driver should parse them to
>>> set appropriate current load during PHY power on.
>>>
>>> This three properties are optional and not mandatory for those platforms
>>> that PCIe PHY can still work with power supply.
>>
>>
>> Uh uh, so the downstream comes finally!
>>
>> No sorry guys, use existing regulator bindings for this.
>>
> 
> Maybe they got inspired by upstream UFS bindings?
> Documentation/devicetree/bindings/ufs/ufs-common.yaml:
> 
> vcc-max-microamp
> vccq-max-microamp
> vccq2-max-microamp

And it is already an ABI, so we cannot do anything about it.

> 
> Regulator binding only describes the min/max load for the regulators and not

No, it exactly describes min/max consumers can use. Let's quote:
"largest current consumers may set"
It is all about consumers.

> consumers. What if the consumers need to set variable load per platform? Should

Then each platform uses regulator API or regulator bindings to set it? I
don't see the problem here.

> they hardcode the load in driver? (even so, the load should not vary for each
> board).

The load must vary per board, because regulators vary per board. Of
course in practice most designs could be the same, but regulators and
their limits are always properties of the board, not the SoC.

Best regards,
Krzysztof

  reply	other threads:[~2024-12-11  8:09 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-04 10:52 [PATCH 0/3] pci: qcom: Add PCIe setting current load support Ziyue Zhang
2024-12-04 10:52 ` [PATCH 1/3] dt-bindings: phy: qcom,qmp-pcie: add optional current load properties Ziyue Zhang
2024-12-05 10:23   ` Krzysztof Kozlowski
2024-12-11  6:20     ` Manivannan Sadhasivam
2024-12-11  8:09       ` Krzysztof Kozlowski [this message]
2024-12-11  8:24         ` Manivannan Sadhasivam
2024-12-11  9:52           ` Krzysztof Kozlowski
2024-12-11 10:34             ` Krzysztof Kozlowski
2024-12-11 11:50             ` Manivannan Sadhasivam
2024-12-12  7:29               ` Ziyue Zhang
2024-12-12  7:31                 ` Krzysztof Kozlowski
2024-12-12  7:30               ` Krzysztof Kozlowski
2024-12-04 10:52 ` [PATCH 2/3] phy: qcom: qmp-pcie: add current load vote/devote for PCIe PHY Ziyue Zhang
2024-12-05 16:31   ` Konrad Dybcio
2024-12-04 10:52 ` [PATCH 3/3] arm64: dts: qcom: qcs615: add pcie phy max current property Ziyue Zhang
2024-12-11  6:26   ` Manivannan Sadhasivam
2024-12-12  7:32     ` Ziyue Zhang
2024-12-26  5:09   ` Bjorn Andersson

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=33697bd9-02f4-4a9a-b8c0-4930d7fdaee2@kernel.org \
    --to=krzk@kernel.org \
    --cc=abel.vesa@linaro.org \
    --cc=andersson@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dmitry.baryshkov@linaro.org \
    --cc=kishon@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=manivannan.sadhasivam@linaro.org \
    --cc=neil.armstrong@linaro.org \
    --cc=quic_ziyuzhan@quicinc.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