On Wed, Dec 11, 2024 at 10:52:11AM +0100, Krzysztof Kozlowski wrote:
On 11/12/2024 09:24, Manivannan Sadhasivam wrote:What? I think there is a misunderstanding here. The intention of these proposed
On Wed, Dec 11, 2024 at 09:09:18AM +0100, Krzysztof Kozlowski wrote:
On 11/12/2024 07:20, Manivannan Sadhasivam wrote:How the consumer drivers are supposed to know the optimum load?
On Thu, Dec 05, 2024 at 11:23:11AM +0100, Krzysztof Kozlowski wrote:And it is already an ABI, so we cannot do anything about it.
On Wed, Dec 04, 2024 at 06:52:47PM +0800, Ziyue Zhang wrote:Maybe they got inspired by upstream UFS bindings?
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.
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 notNo, 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? ShouldThen 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 eachThe load must vary per board, because regulators vary per board. Of
board).
course in practice most designs could be the same, but regulators and
their limits are always properties of the board, not the SoC.
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
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.
IfThere is a difference. Regulator properties are just threshold. So unless the
these are constraints per board, then regulator properties apply and
there is no difference between this "vdd-max-microamp = 10" and
"regulator-max-microamp".
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 andThe consumer driver may request different loads based on their operational
very limited and you should use OPP table.
state.
- Mani