From: Rob Herring <robh@kernel.org> To: Max Krummenacher <max.oss.09@gmail.com> Cc: max.krummenacher@toradex.com, Ulf Hansson <ulf.hansson@linaro.org>, linux-pm@vger.kernel.org, Francesco Dolcini <francesco.dolcini@toradex.com>, Mark Brown <broonie@kernel.org>, "Rafael J . Wysocki" <rafael@kernel.org>, Kevin Hilman <khilman@kernel.org>, Andrejs Cainikovs <andrejs.cainikovs@toradex.com>, Biju Das <biju.das.jz@bp.renesas.com>, Bjorn Andersson <bjorn.andersson@linaro.org>, Catalin Marinas <catalin.marinas@arm.com>, Dmitry Baryshkov <dmitry.baryshkov@linaro.org>, Fabio Estevam <festevam@gmail.com>, Geert Uytterhoeven <geert+renesas@glider.be>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Marcel Ziswiler <marcel.ziswiler@toradex.com>, NXP Linux Team <linux-imx@nxp.com>, Pengutronix Kernel Team <kernel@pengutronix.de>, Sascha Hauer <s.hauer@pengutronix.de>, Shawn Guo <shawnguo@kernel.org>, Vinod Koul <vkoul@kernel.org>, Will Deacon <will@kernel.org>, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v1 0/5] power: domain: Add driver for a PM domain provider which controls Date: Mon, 13 Jun 2022 13:15:49 -0600 [thread overview] Message-ID: <20220613191549.GA4092455-robh@kernel.org> (raw) In-Reply-To: <20220609150851.23084-1-max.oss.09@gmail.com> On Thu, Jun 09, 2022 at 05:08:46PM +0200, Max Krummenacher wrote: > From: Max Krummenacher <max.krummenacher@toradex.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... > This series adds a PM domain provider driver which enables/disables > a regulator to control its power state. Additionally, marked with RFC, > it adds two commits which actually make use of the new driver to > instantiate a power domain provider and have a number of power > domain consumers use the power domain. > > The perceived use case is to control a common power domain used by > several devices for which not all device drivers nessesarily have > a means to control a regulator. Why wouldn't they have means? > It also handles the suspend / resume use case for such devices, > the generic power domain framework will disable the domain once the > last device has been suspend and will enable it again before resuming > the first device. > The generic power domain code handles a power domain consumer > generically outside of the driver's code. (assuming the 'power-domains' > property references exactly one power domain). That's Linux implementation details. > This allows to use the "regulator-pm-pd" driver with an arbitrary > device just by adding the 'power-domains' property to the devices > device tree node. However the device's dt-bindings schema likely does > not allow the property 'power-domains'. > One way to solve this would be to allow 'power-domains' globally > similarly how 'status' and other common properties are allowed as > implicit properties. No. For 'power-domains' bindings have to define how many there are and what each one is. Rob _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Rob Herring <robh@kernel.org> To: Max Krummenacher <max.oss.09@gmail.com> Cc: max.krummenacher@toradex.com, Ulf Hansson <ulf.hansson@linaro.org>, linux-pm@vger.kernel.org, Francesco Dolcini <francesco.dolcini@toradex.com>, Mark Brown <broonie@kernel.org>, "Rafael J . Wysocki" <rafael@kernel.org>, Kevin Hilman <khilman@kernel.org>, Andrejs Cainikovs <andrejs.cainikovs@toradex.com>, Biju Das <biju.das.jz@bp.renesas.com>, Bjorn Andersson <bjorn.andersson@linaro.org>, Catalin Marinas <catalin.marinas@arm.com>, Dmitry Baryshkov <dmitry.baryshkov@linaro.org>, Fabio Estevam <festevam@gmail.com>, Geert Uytterhoeven <geert+renesas@glider.be>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Marcel Ziswiler <marcel.ziswiler@toradex.com>, NXP Linux Team <linux-imx@nxp.com>, Pengutronix Kernel Team <kernel@pengutronix.de>, Sascha Hauer <s.hauer@pengutronix.de>, Shawn Guo <shawnguo@kernel.org>, Vinod Koul <vkoul@kernel.org>, Will Deacon <will@kernel.org>, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v1 0/5] power: domain: Add driver for a PM domain provider which controls Date: Mon, 13 Jun 2022 13:15:49 -0600 [thread overview] Message-ID: <20220613191549.GA4092455-robh@kernel.org> (raw) In-Reply-To: <20220609150851.23084-1-max.oss.09@gmail.com> On Thu, Jun 09, 2022 at 05:08:46PM +0200, Max Krummenacher wrote: > From: Max Krummenacher <max.krummenacher@toradex.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... > This series adds a PM domain provider driver which enables/disables > a regulator to control its power state. Additionally, marked with RFC, > it adds two commits which actually make use of the new driver to > instantiate a power domain provider and have a number of power > domain consumers use the power domain. > > The perceived use case is to control a common power domain used by > several devices for which not all device drivers nessesarily have > a means to control a regulator. Why wouldn't they have means? > It also handles the suspend / resume use case for such devices, > the generic power domain framework will disable the domain once the > last device has been suspend and will enable it again before resuming > the first device. > The generic power domain code handles a power domain consumer > generically outside of the driver's code. (assuming the 'power-domains' > property references exactly one power domain). That's Linux implementation details. > This allows to use the "regulator-pm-pd" driver with an arbitrary > device just by adding the 'power-domains' property to the devices > device tree node. However the device's dt-bindings schema likely does > not allow the property 'power-domains'. > One way to solve this would be to allow 'power-domains' globally > similarly how 'status' and other common properties are allowed as > implicit properties. No. For 'power-domains' bindings have to define how many there are and what each one is. Rob
next prev parent reply other threads:[~2022-06-13 19:17 UTC|newest] Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-06-09 15:08 [PATCH v1 0/5] power: domain: Add driver for a PM domain provider which controls Max Krummenacher 2022-06-09 15:08 ` Max Krummenacher 2022-06-09 15:08 ` [PATCH v1 1/5] dt-bindings: power: Add bindings for a power domain controlled by a regulator Max Krummenacher 2022-06-10 2:57 ` Rob Herring 2022-06-15 15:19 ` Max Krummenacher 2022-06-15 17:16 ` Krzysztof Kozlowski 2022-06-14 7:23 ` Geert Uytterhoeven 2022-06-15 15:18 ` Max Krummenacher 2022-06-09 15:08 ` [PATCH v1 2/5] pm: add regulator power domain controller Max Krummenacher 2022-06-09 15:08 ` [PATCH v1 3/5] MAINTAINERS: add REGULATOR POWER DOMAIN Max Krummenacher 2022-06-09 15:08 ` [RFC PATCH v1 4/5] arm64: defconfig: Enable generic power domain controller controlling a regulator Max Krummenacher 2022-06-09 15:08 ` Max Krummenacher 2022-06-09 15:08 ` [RFC PATCH v1 5/5] ARM64: verdin-imx8mm: use regulator power domain to model sleep-moci Max Krummenacher 2022-06-09 15:08 ` Max Krummenacher 2022-06-14 7:29 ` Geert Uytterhoeven 2022-06-14 7:29 ` Geert Uytterhoeven 2022-06-15 15:32 ` Max Krummenacher 2022-06-15 15:32 ` Max Krummenacher 2022-06-13 19:15 ` Rob Herring [this message] 2022-06-13 19:15 ` [PATCH v1 0/5] power: domain: Add driver for a PM domain provider which controls Rob Herring 2022-06-14 7:22 ` Geert Uytterhoeven 2022-06-14 7:22 ` Geert Uytterhoeven 2022-06-15 16:10 ` Max Krummenacher 2022-06-15 16:10 ` Max Krummenacher 2022-06-15 17:15 ` Krzysztof Kozlowski 2022-06-15 17:15 ` Krzysztof Kozlowski 2022-06-15 17:31 ` Marcel Ziswiler 2022-06-15 17:31 ` Marcel Ziswiler 2022-06-15 17:37 ` Krzysztof Kozlowski 2022-06-15 17:37 ` Krzysztof Kozlowski 2022-06-15 18:13 ` Marcel Ziswiler 2022-06-15 18:13 ` Marcel Ziswiler 2022-06-15 18:48 ` Dmitry Baryshkov 2022-06-15 18:48 ` Dmitry Baryshkov 2022-06-15 20:48 ` Krzysztof Kozlowski 2022-06-15 20:48 ` Krzysztof Kozlowski 2022-06-15 18:24 ` Robin Murphy 2022-06-15 18:24 ` Robin Murphy 2022-06-15 19:12 ` Mark Brown 2022-06-15 19:12 ` Mark Brown 2022-06-15 21:14 ` Ulf Hansson 2022-06-15 21:14 ` Ulf Hansson 2022-06-16 12:50 ` Linus Walleij 2022-06-16 12:50 ` Linus Walleij 2022-06-23 16:14 ` Max Krummenacher 2022-06-23 16:14 ` Max Krummenacher 2022-07-13 11:43 ` Ulf Hansson 2022-07-13 11:43 ` Ulf Hansson 2022-07-18 9:49 ` Linus Walleij 2022-07-18 9:49 ` Linus Walleij 2022-07-26 16:03 ` Francesco Dolcini 2022-07-26 16:03 ` Francesco Dolcini 2022-07-28 9:37 ` Ulf Hansson 2022-07-28 9:37 ` Ulf Hansson 2022-07-28 11:21 ` Francesco Dolcini 2022-07-28 11:21 ` Francesco Dolcini 2022-08-26 13:50 ` Ulf Hansson 2022-08-26 13:50 ` Ulf Hansson 2022-09-09 14:22 ` Francesco Dolcini 2022-09-09 14:22 ` Francesco Dolcini 2022-09-22 13:49 ` Ulf Hansson 2022-09-22 13:49 ` Ulf Hansson 2022-09-23 18:00 ` Krzysztof Kozlowski 2022-09-23 18:00 ` Krzysztof Kozlowski 2022-09-26 10:12 ` Ulf Hansson 2022-09-26 10:12 ` Ulf Hansson 2022-09-26 15:11 ` Krzysztof Kozlowski 2022-09-26 15:11 ` Krzysztof Kozlowski 2022-09-27 9:48 ` Ulf Hansson 2022-09-27 9:48 ` Ulf Hansson 2022-09-27 12:49 ` Geert Uytterhoeven 2022-09-27 12:49 ` Geert Uytterhoeven 2022-09-27 14:26 ` Krzysztof Kozlowski 2022-09-27 14:26 ` Krzysztof Kozlowski 2022-09-28 7:59 ` Ulf Hansson 2022-09-28 7:59 ` Ulf Hansson
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20220613191549.GA4092455-robh@kernel.org \ --to=robh@kernel.org \ --cc=andrejs.cainikovs@toradex.com \ --cc=biju.das.jz@bp.renesas.com \ --cc=bjorn.andersson@linaro.org \ --cc=broonie@kernel.org \ --cc=catalin.marinas@arm.com \ --cc=devicetree@vger.kernel.org \ --cc=dmitry.baryshkov@linaro.org \ --cc=festevam@gmail.com \ --cc=francesco.dolcini@toradex.com \ --cc=geert+renesas@glider.be \ --cc=kernel@pengutronix.de \ --cc=khilman@kernel.org \ --cc=krzysztof.kozlowski+dt@linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-imx@nxp.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-pm@vger.kernel.org \ --cc=marcel.ziswiler@toradex.com \ --cc=max.krummenacher@toradex.com \ --cc=max.oss.09@gmail.com \ --cc=rafael@kernel.org \ --cc=s.hauer@pengutronix.de \ --cc=shawnguo@kernel.org \ --cc=ulf.hansson@linaro.org \ --cc=vkoul@kernel.org \ --cc=will@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.