On Mon, Aug 21, 2023 at 8:22 AM Shenwei Wang <shenwei.wang@xxxxxxx> wrote: > > > > > -----Original Message----- > > From: Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx> > > Sent: Saturday, August 19, 2023 3:04 AM > > To: Shenwei Wang <shenwei.wang@xxxxxxx>; Rob Herring > > <robh+dt@xxxxxxxxxx> > > Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@xxxxxxxxxx>; Conor Dooley > > <conor+dt@xxxxxxxxxx>; Ulf Hansson <ulf.hansson@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 > > > > Caution: This is an external email. Please take care when clicking links or > > opening attachments. When in doubt, report the message using the 'Report this > > email' button > > > > > > >> > > >> This needs to answer why we need this. > > >> > > >> It looks like just an abstraction layer to make regulators look like > > >> a power domain. > > >> > > > > > > Yes, it is a wrapper that allows using regulators as a power domain. > > > This removes the need to add regulator operating code in each consumer > > > device driver. As a power domain, the regulator will be managed > > > automatically by the device driver framework and PM subsystem. > > > > > > This is very useful when a device's power is controlled by a GPIO pin, > > > which currently requires using the fixed-regulator to achieve the same > > > purpose. However, the fixed-regulator approach may have to add code in the > > driver in order to use it. > > > > Why do you start discussion from zero ignoring all previous history of this > > patchset? > > > > Thank you for providing the link. After reviewing the entire thread, I still don't understand how > to proceed. What is the conclusion regarding this commonly used use case but overlooked feature > in the upstream kernel? Overlooked implies we missed and ignored it, but the same concept has been submitted twice and rejected twice. What use case cannot be supported? The detail that power-domains get handled automatically is an implementation detail in the kernel (currently). That could easily change and you'd be in the same position as with regulator supplies. We could just as easily decide to make the driver core turn on all supplies in a node. That would give you the same "feature". Why would you design your DT around implementation decisions of the OS? Rob
