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

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

 



On 28/08/2023 11:59, Ulf Hansson wrote:
> On Sat, 26 Aug 2023 at 19:31, Krzysztof Kozlowski
> <krzysztof.kozlowski@xxxxxxxxxx> wrote:
>>
>> On 25/08/2023 17:44, Shenwei Wang wrote:
>>>>
>>>> The genpd provider then needs to be a consumer of the resources it needs. In
>>>> this case a couple of regulators it seems like.
>>>>
>>>
>>> If I understood your reply correctly,  it seems that the current implementation of
>>> regulator-pd is what you have described. Please correct me if I'm mistaken.
>>>
>>> The following are the diff of scu-pd and this regulator-pd.
>>>
>>>     power-controller {                                                    power-controller {
>>>         compatible = "fsl,imx8qxp-scu-pd", "fsl,scu-pd";      |               compatible = "regulator-power-domain";
>>>         #power-domain-cells = <1>;                                    #power-domain-cells = <1>;
>>>                                                             >
>>>                                                             >         regulator-number = <2>;
>>>                                                             >         regulator-0-supply = <&reg1>;
>>>                                                             >         regulator-1-supply = <&reg2>;
>>>     };                                                                    };
>>>
>>> Are you suggesting to move the regulator-pd to the imx directory and add a company prefix
>>> to the compatible string?
>>
>> There is no such part of iMX processor as such regulator-power-domain,
>> so I don't recommend that approach. DTS nodes represent hardware, not
>> your SW layers.
> 
> I would agree if this was pure SW layers, but I don't think it is. At
> least, if I have understood the earlier discussions correctly [1],
> there are certainly one or more power-domains here. The power-domains
> just happen to be powered through something that can be modelled as a
> regular regulator(s). No?

No. It was for controlling power of multiple devices, supplied by
multiple different or similar regulators, where Linux drivers for these
devices (so not even all drivers...) do not have regulator control. The
bindings for these devices allow power-domains, but not regulator.

There are no multiple power domains in the problem. Even term "power
domain" is questionable here, because we tend to look power domain as
part of SoC. Here it is some selected part of the circuitry, like few
totally independent devices which share purpose and power rails.

But more important is my first paragraph - this is purely to avoid
adding regulators to these devices.

Best regards,
Krzysztof




[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