Re: [PATCH 1/2] dt-bindings: power: Add regulator-pd yaml file

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> -----Original Message-----
> From: Rob Herring <robh+dt@xxxxxxxxxx>
> Sent: Monday, August 28, 2023 4:14 PM
> To: Shenwei Wang <shenwei.wang@xxxxxxx>
> Cc: Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx>; Ulf Hansson
> <ulf.hansson@xxxxxxxxxx>; Krzysztof Kozlowski
> <krzysztof.kozlowski+dt@xxxxxxxxxx>; Conor Dooley <conor+dt@xxxxxxxxxx>;
> Liam Girdwood <lgirdwood@xxxxxxxxx>; Mark Brown <broonie@xxxxxxxxxx>;
> imx@xxxxxxxxxxxxxxx; devicetree@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx;
> dl-linux-imx <linux-imx@xxxxxxx>
> 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




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux