On 15/06/2022 21:13, Marcel Ziswiler wrote:
On Wed, 2022-06-15 at 10:37 -0700, Krzysztof Kozlowski wrote:
On 15/06/2022 10:31, Marcel Ziswiler wrote:
Hi
On Wed, 2022-06-15 at 10:15 -0700, Krzysztof Kozlowski wrote:
On 15/06/2022 09:10, Max Krummenacher wrote:
Hi
On Tue, Jun 14, 2022 at 9:22 AM Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote:
Hi Rob,
On Mon, Jun 13, 2022 at 9:15 PM Rob Herring <robh@xxxxxxxxxx> wrote:
On Thu, Jun 09, 2022 at 05:08:46PM +0200, Max Krummenacher wrote:
From: Max Krummenacher <max.krummenacher@xxxxxxxxxxx>
its power enable by using a regulator.
The currently implemented PM domain providers are all specific to
a particular system on chip.
Yes, power domains tend to be specific to an SoC... 'power-domains' is
supposed to be power islands in a chip. Linux 'PM domains' can be
anything...
I don't see why such power islands should be restricted to a SoC. You can
build the exact same idea on a PCB or even more modular designs.
In the SoC these power islands are more-or-less defined. These are real
regions gated by some control knob.
Calling few devices on a board "power domain" does not make it a power
domain. There is no grouping, there is no control knob.
Aren't you now re-implementing regulator supplies? How is this different
than existing supplies?
I believe the biggest difference between power-domains and regulator-supplies lays in the former being
driver
agnostic while the later is driver specific.
That's one way to look, but the other way (matching the bindings
purpose) is to look at hardware. You have physical wire / voltage rail
supply - use regulator supply. In the terms of the hardware - what is
that power domain? It's a concept, not a physical object.
Well, but how can that concept then exist within the SoC but not outside? I don't get it. Isn't it just the
exact same physical power gating thingy whether inside the SoC or on a PCB?
Meaning with power-domains one can just add such arbitrary
structure to the device tree without any further driver specific changes/handling required. While with
regulator-supplies each and every driver actually needs to have driver specific handling thereof added. Or
do I
miss anything?
Thanks for clarification but I am not sure if it matches the purpose of
bindings and DTS. You can change the implementation as well to have
implicit regulators. No need for new bindings for that.
Okay, maybe that would also work, of course. So basically add a new binding which allows adding regulators to
arbitrary nodes which then will be generically handled by e.g. runtime PM. Almost something like assigned-
clocks [1] you mean? I guess that could work. Remember that's why Max posted it as an RFC to get such feedback.
Thanks for further refining those ideas.
Please do not do this. You have an external device. It has some input
voltage rails. Please define -supply properties for each of the voltage
rails. Explicitly power them on and off. Use fixed-regulator for your
GPIO regulators. Other boards might have other ways to control the power
supply.
Then define the pm_runtime callbacks doing proper work for you. If you
wish to do the magic, consider looking on the pm_clock.h interface (and
adding the pm_regulators.h). But this approach can also be frowned upon
by the PM maintainers. Nevertheless, this is the driver/core issue. The
DT interface should be the same: a set of regulators and a set of
-supply properties.
--
With best wishes
Dmitry
