Messages in this thread | | | From | Shenwei Wang <> | Subject | Re: [PATCH 1/2] dt-bindings: power: Add regulator-pd yaml file | Date | Tue, 29 Aug 2023 13:21:40 +0000 |
| |
> -----Original Message----- > From: Rob Herring <robh+dt@kernel.org> > Sent: Monday, August 28, 2023 4:14 PM > To: Shenwei Wang <shenwei.wang@nxp.com> > Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>; Ulf Hansson > <ulf.hansson@linaro.org>; Krzysztof Kozlowski > <krzysztof.kozlowski+dt@linaro.org>; Conor Dooley <conor+dt@kernel.org>; > Liam Girdwood <lgirdwood@gmail.com>; Mark Brown <broonie@kernel.org>; > imx@lists.linux.dev; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; > dl-linux-imx <linux-imx@nxp.com> > Subject: [EXT] Re: [PATCH 1/2] dt-bindings: power: Add regulator-pd yaml file > > > > The fixed-regulator is a virtual regulator driver that uses the GPIO pin. > > > > > > We do not talk about drivers but bindings and DTS. Why do you bring > > > again drivers, all the time? > > > > > > > You claimed this > > > > as a hardware chip. > > > > > > ??? Sorry, this is getting boring. The DTS-snippet is a hardware chip. > > > If it is not, then drop it from your DTS. I insist. Srsly, third time I insist. > > > > > > > > > > > > > > The regulator-pd driver also uses the same GPIO pin. > > > > > > Again, what is with the drivers? Can you stop bringing it to the discussion? > > > > > > > I have to admit you have a real talent for debate. > > It takes 2... > > You've gotten feedback from multiple people that your proposal is not going to > be accepted. The prior attempt of the same thing had similar feedback from > even more people. Please go re-read the responses until you understand. > > For fixed-regulator, I can tell you very easily what the h/w looks like: > > Vfix---|gate|---Vfix-gated > | > GPIO--------| > > 'gate' here may be a chip or discrete transistor. That's a very common board > level component. >
The difference is in how we model the hardware. In your example, you model the GPIO as a simple switch to fit the fixed regulator use case. However, we could also model the same GPIO as a power domain if we consider the device connected to it. This allows for more nuanced hardware modeling based on the context and components involved.
Regulator-1 -+-> [Device A]
This give you one regulator(via GPIO Pin) and one power domain (Device A).
The following are the example diagram given by the power domain overview doc:
Regulator-1 -+-> Regulator-2 -+-> [Consumer A] | +-> [Consumer B]
This gives us two regulators and two power domains:
- Domain 1: Regulator-2, Consumer B. - Domain 2: Consumer A.
Thanks, Shenwei
> If you want to discuss this any further, describe the h/w in terms of simplified > schematics. Otherwise, there is nothing more to discuss. > > Rob
| |