| Message ID | 20241204105249.3544114-2-quic_ziyuzhan@quicinc.com |
|---|---|
| State | New |
| Headers | show |
| Series | pci: qcom: Add PCIe setting current load support | expand |
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. Best regards, Krzysztof
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 Regulator binding only describes the min/max load for the regulators and not consumers. What if the consumers need to set variable load per platform? Should they hardcode the load in driver? (even so, the load should not vary for each board). - Mani
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
On Wed, Dec 11, 2024 at 09:09:18AM +0100, Krzysztof Kozlowski wrote: > 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. > How the consumer drivers are supposed to know the optimum load? I don't see how the consumer drivers can set the load without hardcoding the values. And I could see from UFS properties that each board has different values. - Mani
On 11/12/2024 09:24, Manivannan Sadhasivam wrote: > On Wed, Dec 11, 2024 at 09:09:18AM +0100, Krzysztof Kozlowski wrote: >> 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. >> > > How the consumer drivers are supposed to know the optimum load? > > I don't see how the consumer drivers can set the load without hardcoding the > values. And I could see from UFS properties that each board has different > values. Drivers do not need to know, it's not the driver's responsibility. If these are constraints per board, then regulator properties apply and there is no difference between this "vdd-max-microamp = 10" and "regulator-max-microamp". If this varies runtime, then your property is already not suitable and very limited and you should use OPP table. Best regards, Krzysztof
On 11/12/2024 10:52, Krzysztof Kozlowski wrote: > On 11/12/2024 09:24, Manivannan Sadhasivam wrote: >> On Wed, Dec 11, 2024 at 09:09:18AM +0100, Krzysztof Kozlowski wrote: >>> 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. >>> >> >> How the consumer drivers are supposed to know the optimum load? >> >> I don't see how the consumer drivers can set the load without hardcoding the >> values. And I could see from UFS properties that each board has different >> values. > > > Drivers do not need to know, it's not the driver's responsibility. If > these are constraints per board, then regulator properties apply and > there is no difference between this "vdd-max-microamp = 10" and > "regulator-max-microamp". > > If this varies runtime, then your property is already not suitable and > very limited and you should use OPP table. > Plus let's recap the commit msg which is supposed to fully explain the hardware: "the power supply for PCIe PHY is not able to provide enough current" Well, that's 100% property of power supply - so the regulator node in PMIC, not the UFS device (consumer). With that commit msg it is clear the properties are placed wrongly. However maybe just commit msg is wrong, but then how could we possibly know what is the real hardware, right? :) Best regards, Krzysztof
On Wed, Dec 11, 2024 at 10:52:11AM +0100, Krzysztof Kozlowski wrote: > On 11/12/2024 09:24, Manivannan Sadhasivam wrote: > > On Wed, Dec 11, 2024 at 09:09:18AM +0100, Krzysztof Kozlowski wrote: > >> 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. > >> > > > > How the consumer drivers are supposed to know the optimum load? > > > > I don't see how the consumer drivers can set the load without hardcoding the > > values. And I could see from UFS properties that each board has different > > values. > > > Drivers do not need to know, it's not the driver's responsibility. If What? I think there is a misunderstanding here. The intention of these proposed properties is to allow the PHY driver to set the required load of the regulator using regulator_set_load() API. As per the API description: 'Consumer devices notify their supply regulator of the maximum power they will require (can be taken from device datasheet in the power consumption tables) when they change operational status and hence power state'. IIUC, your concern is that the devicetree shouldn't specify the load for each consumer but just the min/max load of the regulator. And the consumer driver should figure out the load and set it accordingly. Correct me if I'm wrong. In that case, I was wondering if the load set by the driver is going to vary between platforms (boards) or not (question to Ziyue Zhang). If it varies between SoC, then we can hardcode the load in driver based on compatible. > If > these are constraints per board, then regulator properties apply and > there is no difference between this "vdd-max-microamp = 10" and > "regulator-max-microamp". > There is a difference. Regulator properties are just threshold. So unless the consumer sets the load, they won't take effect. I think you got confused by the 'max' wording in the proposed properties? > If this varies runtime, then your property is already not suitable and > very limited and you should use OPP table. > The consumer driver may request different loads based on their operational state. - Mani
在 12/11/2024 7:50 PM, Manivannan Sadhasivam 写道: > On Wed, Dec 11, 2024 at 10:52:11AM +0100, Krzysztof Kozlowski wrote: >> On 11/12/2024 09:24, Manivannan Sadhasivam wrote: >>> On Wed, Dec 11, 2024 at 09:09:18AM +0100, Krzysztof Kozlowski wrote: >>>> 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. >>>> >>> How the consumer drivers are supposed to know the optimum load? >>> >>> I don't see how the consumer drivers can set the load without hardcoding the >>> values. And I could see from UFS properties that each board has different >>> values. >> >> Drivers do not need to know, it's not the driver's responsibility. If > What? I think there is a misunderstanding here. The intention of these proposed > properties is to allow the PHY driver to set the required load of the regulator > using regulator_set_load() API. As per the API description: > > 'Consumer devices notify their supply regulator of the maximum power they will > require (can be taken from device datasheet in the power consumption tables) > when they change operational status and hence power state'. > > IIUC, your concern is that the devicetree shouldn't specify the load for each > consumer but just the min/max load of the regulator. And the consumer driver > should figure out the load and set it accordingly. > > Correct me if I'm wrong. > > In that case, I was wondering if the load set by the driver is going to vary > between platforms (boards) or not (question to Ziyue Zhang). If it varies > between SoC, then we can hardcode the load in driver based on compatible. Hi Mani, Krzystof Now we set the current to 165mA which is the max power supply the regulator can provide, so this is platform(boards) related. But we think PCIe PHY needs to set the current value we need, which is soc related. BRs Ziyue >> If >> these are constraints per board, then regulator properties apply and >> there is no difference between this "vdd-max-microamp = 10" and >> "regulator-max-microamp". >> > There is a difference. Regulator properties are just threshold. So unless the > consumer sets the load, they won't take effect. I think you got confused by the > 'max' wording in the proposed properties? > >> If this varies runtime, then your property is already not suitable and >> very limited and you should use OPP table. >> > The consumer driver may request different loads based on their operational > state. > > - Mani >
On 11/12/2024 12:50, Manivannan Sadhasivam wrote: > On Wed, Dec 11, 2024 at 10:52:11AM +0100, Krzysztof Kozlowski wrote: >> On 11/12/2024 09:24, Manivannan Sadhasivam wrote: >>> On Wed, Dec 11, 2024 at 09:09:18AM +0100, Krzysztof Kozlowski wrote: >>>> 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. >>>> >>> >>> How the consumer drivers are supposed to know the optimum load? >>> >>> I don't see how the consumer drivers can set the load without hardcoding the >>> values. And I could see from UFS properties that each board has different >>> values. >> >> >> Drivers do not need to know, it's not the driver's responsibility. If > > What? I think there is a misunderstanding here. The intention of these proposed > properties is to allow the PHY driver to set the required load of the regulator > using regulator_set_load() API. As per the API description: This makes sense. I referred to property description to learn what it is really doing. I found nothing, because it is empty, so that's how we waste time... > > 'Consumer devices notify their supply regulator of the maximum power they will > require (can be taken from device datasheet in the power consumption tables) > when they change operational status and hence power state'. > > IIUC, your concern is that the devicetree shouldn't specify the load for each My concern is that Qualcomm put here regulator constraints and call them device load. And empty property name does not help me to think other way. How can I verify the number that it was taken from UFS device manual, not from PMIC? > consumer but just the min/max load of the regulator. And the consumer driver > should figure out the load and set it accordingly. With your above explanation I think the actual consumer load, if it is depending on the board, have place in DT. But: > > Correct me if I'm wrong. > > In that case, I was wondering if the load set by the driver is going to vary > between platforms (boards) or not (question to Ziyue Zhang). If it varies > between SoC, then we can hardcode the load in driver based on compatible. Yeah, maybe each it is implied by compatible and not board dependent. Then just like everything implied by compatibles: should not be placed in DT. We already follow this approach for several other Qualcomm drivers, e.g. display. > >> If >> these are constraints per board, then regulator properties apply and >> there is no difference between this "vdd-max-microamp = 10" and >> "regulator-max-microamp". >> > > There is a difference. Regulator properties are just threshold. So unless the > consumer sets the load, they won't take effect. I think you got confused by the > 'max' wording in the proposed properties? Yes and confused by its description in the binding. > >> If this varies runtime, then your property is already not suitable and >> very limited and you should use OPP table. >> > > The consumer driver may request different loads based on their operational > state. Then anyway maybe this should be OPP table (assuming it is board specific). Best regards, Krzysztof
On 12/12/2024 08:29, Ziyue Zhang wrote: > >> In that case, I was wondering if the load set by the driver is going to vary >> between platforms (boards) or not (question to Ziyue Zhang). If it varies >> between SoC, then we can hardcode the load in driver based on compatible. > > Hi Mani, Krzystof > > Now we set the current to 165mA which is the max power supply the regulator > can provide, so this is platform(boards) related. But we think PCIe PHY needs Yeah, so that's the answer to what I asked just a second ago - you do not put there device load. You put there regulator constraints. > to set the current value we need, which is soc related. So move it away from DT. I don't care what's in the driver, so you can put there whatever fake value. Best regards, Krzysztof
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 34d977af9263..0e2715301c54 100644 --- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml @@ -78,10 +78,16 @@ properties: vdda-phy-supply: true + vdda-phy-max-microamp: true + vdda-pll-supply: true + vdda-pll-max-microamp: true + vdda-qref-supply: true + vdda-qref-max-microamp: true + qcom,4ln-config-sel: description: PCIe 4-lane configuration $ref: /schemas/types.yaml#/definitions/phandle-array @@ -261,6 +267,7 @@ examples: vdda-phy-supply = <&vreg_l6d>; vdda-pll-supply = <&vreg_l4d>; + vdda-pll-max-microamp = <165000>; #clock-cells = <0>; clock-output-names = "pcie_2b_pipe_clk"; @@ -288,6 +295,7 @@ examples: vdda-phy-supply = <&vreg_l6d>; vdda-pll-supply = <&vreg_l4d>; + vdda-pll-max-microamp = <165000>; qcom,4ln-config-sel = <&tcsr 0xa044 0>;
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. Signed-off-by: Ziyue Zhang <quic_ziyuzhan@quicinc.com> --- .../bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml | 8 ++++++++ 1 file changed, 8 insertions(+)