[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <dacd4a2d-a2b9-d2c2-4d47-f030dd01ee25@arm.com>
Date: Wed, 15 Jun 2022 19:24:50 +0100
From: Robin Murphy <robin.murphy@....com>
To: Marcel Ziswiler <marcel.ziswiler@...adex.com>,
"max.oss.09@...il.com" <max.oss.09@...il.com>,
"krzysztof.kozlowski@...aro.org" <krzysztof.kozlowski@...aro.org>,
"geert@...ux-m68k.org" <geert@...ux-m68k.org>
Cc: "linux-imx@....com" <linux-imx@....com>,
Francesco Dolcini <francesco.dolcini@...adex.com>,
"robh@...nel.org" <robh@...nel.org>,
"krzysztof.kozlowski+dt@...aro.org"
<krzysztof.kozlowski+dt@...aro.org>,
"ulf.hansson@...aro.org" <ulf.hansson@...aro.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"dmitry.baryshkov@...aro.org" <dmitry.baryshkov@...aro.org>,
"biju.das.jz@...renesas.com" <biju.das.jz@...renesas.com>,
"catalin.marinas@....com" <catalin.marinas@....com>,
"geert+renesas@...der.be" <geert+renesas@...der.be>,
"bjorn.andersson@...aro.org" <bjorn.andersson@...aro.org>,
"vkoul@...nel.org" <vkoul@...nel.org>,
"shawnguo@...nel.org" <shawnguo@...nel.org>,
"kernel@...gutronix.de" <kernel@...gutronix.de>,
"khilman@...nel.org" <khilman@...nel.org>,
"s.hauer@...gutronix.de" <s.hauer@...gutronix.de>,
Andrejs Cainikovs <andrejs.cainikovs@...adex.com>,
"will@...nel.org" <will@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
"rafael@...nel.org" <rafael@...nel.org>,
"festevam@...il.com" <festevam@...il.com>,
Max Krummenacher <max.krummenacher@...adex.com>,
"broonie@...nel.org" <broonie@...nel.org>
Subject: Re: [PATCH v1 0/5] power: domain: Add driver for a PM domain provider
which controls
On 2022-06-15 18: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@...ux-m68k.org> wrote:
>>>>
>>>> Hi Rob,
>>>>
>>>> On Mon, Jun 13, 2022 at 9:15 PM Rob Herring <robh@...nel.org> wrote:
>>>>> On Thu, Jun 09, 2022 at 05:08:46PM +0200, Max Krummenacher wrote:
>>>>>> From: Max Krummenacher <max.krummenacher@...adex.com>
>>>>>>
>>>>>> 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. 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?
>
> We are really trying to model something where a single GPIO pin (via a GPIO regulator or whatever) can control
> power to a variety of on-board peripherals. And, of course, we envision runtime PM actually making use of it
> e.g. when doing suspend/resume.
FWIW, this really seems to beg the question of PM support in the drivers
for those peripherals. If they'll need to be modified to add
suspend/resume routines anyway, then adding a handful more lines to
control a supply regulator at the same time shouldn't be too big a deal.
Conversely, I'd be surprised if they *did* have PM support if there
wasn't already some way to make use of it.
Multiple consumers sharing a voltage rail provided by a single regulator
is so standard and well-supported that it barely seems worth pointing
out, but for the avoidance of doubt I shall. Adding a new non-standard
way to hide a specific subset of regulator functionality behind behind a
magic driver because it seems like slightly less work than handling it
the well-known established way sounds like a great recipe for technical
debt and future compatibility headaches. What if down the line you end
up with a situation where if device A is suspended, devices B and C are
happy to save some power by running the "domain" at a lower voltage? Do
we stubbornly start duplicating more of the regulator framework in the
magic power domain driver, or is that the point where we have to switch
all the consumers to explicit supplies, and get to regret having "saved"
that effort in the first place...
Cheers,
Robin.
Powered by blists - more mailing lists