.../devicetree/bindings/power/pd-samsung.yaml | 33 ++- .../bindings/soc/google/google,gs101-dtzpc.yaml | 42 ++++ .../bindings/soc/google/google,gs101-pmu.yaml | 97 ++++++++ .../bindings/soc/samsung/exynos-pmu.yaml | 20 -- MAINTAINERS | 2 + drivers/pmdomain/samsung/exynos-pm-domains.c | 262 +++++++++++++++++++-- 6 files changed, 407 insertions(+), 49 deletions(-)
Hi,
This series adds support for the power domains on Google GS101.
There are a few differences compared to SoCs already supported by this
driver:
* register access does not work via plain ioremap() / readl() /
writel().
Instead, the regmap created by the PMU driver must be used (which
uses Arm SMCC calls under the hood).
* DTZPC: a call needs to be made before and after power domain off/on,
to inform the EL3 firmware of the request.
* power domains can and are fed by a regulator rail and therefore
regulator control needed be implemented.
Bullet points 2 and 3 are new since version 4 of this series, and
related changes are in patches 1, 2, 9, and 10. I can merge patch 9
(SMC call) into the gs101 patch (patch 7) if preferred, but for now I
kept them independent to make it easier to see changes compared to
previous versions of this series, and because patch 9 actually applies
to not only gs101, but to many newer Exynos SoCs, and to make patches 9
and 10 themselves easier to review and reason about.
The DT update to add the new required properties on gs101 will be
posted separately.
Signed-off-by: André Draszik <andre.draszik@linaro.org>
---
Changes in v8:
- correct use of ranges (patches 4 && 7) (Rob)
- add missing \n in some of the new log messages (patches 5 && 10)
- Link to v7: https://lore.kernel.org/r/20260306-gs101-pd-v7-0-03f7c7965ba5@linaro.org
Changes in v7:
- really be consistent with quoting (Krzysztof, patch 4)
- drop invalid tested-by tag (Krzysztof, patch 3 & 4)
- Link to v6: https://lore.kernel.org/r/20260305-gs101-pd-v6-0-8cb953c1a723@linaro.org
Changes in v6:
- collect tags
- patch 4: update commit message footer to clarify that while
old/existing DT are now incomplete, they'll be updated once binding
is accepted.
- Link to v5: https://lore.kernel.org/r/20260205-gs101-pd-v5-0-ede49cdb57a6@linaro.org
Changes in v5:
- add domain-supply to binding (patch 2)
- Link to v4: https://lore.kernel.org/r/20260128-gs101-pd-v4-0-cbe7bd5a4060@linaro.org
Changes in v4:
- drop unneeded or already merged patches
- drop patch "pmdomain: samsung: convert to regmap_read_poll_timeout()"
as Marek reported issues on some platforms
- rebase
- DTZPC related changes
- Link to v3: https://lore.kernel.org/r/20251016-gs101-pd-v3-0-7b30797396e7@linaro.org
Changes in v3:
- use additionalProperties, not unevaluatedProperties in patch 2
- fix path in $id in patch 2 (Rob)
- drop comment around 'select' in patch 2 (Rob)
- collect tags
- Link to v2: https://lore.kernel.org/r/20251009-gs101-pd-v2-0-3f4a6db2af39@linaro.org
Changes in v2:
- Krzysztof:
- move google,gs101-pmu binding into separate file
- mark devm_kstrdup_const() patch as fix
- use bool for need_early_sync_state
- merge patches 8 and 10 from v1 series into one patch
- collect tags
- Link to v1: https://lore.kernel.org/r/20251006-gs101-pd-v1-0-f0cb0c01ea7b@linaro.org
---
André Draszik (10):
dt-bindings: soc: google: add google,gs101-dtzpc
dt-bindings: power: samsung: add google,gs101-pd
dt-bindings: soc: samsung: exynos-pmu: move gs101-pmu into separate binding
dt-bindings: soc: google: gs101-pmu: allow power domains as children
pmdomain: samsung: convert to using regmap
pmdomain: samsung: don't hard-code offset for registers to 0 and 4
pmdomain: samsung: add support for google,gs101-pd
pmdomain: samsung: use dev_err() instead of pr_err()
pmdomain: samsung: implement SMC to save / restore TZ config
pmdomain: samsung: implement domain-supply regulator
.../devicetree/bindings/power/pd-samsung.yaml | 33 ++-
.../bindings/soc/google/google,gs101-dtzpc.yaml | 42 ++++
.../bindings/soc/google/google,gs101-pmu.yaml | 97 ++++++++
.../bindings/soc/samsung/exynos-pmu.yaml | 20 --
MAINTAINERS | 2 +
drivers/pmdomain/samsung/exynos-pm-domains.c | 262 +++++++++++++++++++--
6 files changed, 407 insertions(+), 49 deletions(-)
---
base-commit: 5c9e55fecf9365890c64f14761a80f9413a3b1d1
change-id: 20251001-gs101-pd-d4dc97d70a84
Best regards,
--
André Draszik <andre.draszik@linaro.org>
On Wed, 18 Mar 2026 15:27:45 +0000, André Draszik wrote:
> This series adds support for the power domains on Google GS101.
>
> There are a few differences compared to SoCs already supported by this
> driver:
> * register access does not work via plain ioremap() / readl() /
> writel().
> Instead, the regmap created by the PMU driver must be used (which
> uses Arm SMCC calls under the hood).
> * DTZPC: a call needs to be made before and after power domain off/on,
> to inform the EL3 firmware of the request.
> * power domains can and are fed by a regulator rail and therefore
> regulator control needed be implemented.
>
> [...]
Applied, thanks!
[01/10] dt-bindings: soc: google: add google,gs101-dtzpc
https://git.kernel.org/krzk/linux/c/10084aeadadfab72648f6ed1cc78f7cd87b861ba
[03/10] dt-bindings: soc: samsung: exynos-pmu: move gs101-pmu into separate binding
https://git.kernel.org/krzk/linux/c/3ec3c42b426fe5e2b48ff19c551dec50bc78788c
[04/10] dt-bindings: soc: google: gs101-pmu: allow power domains as children
https://git.kernel.org/krzk/linux/c/c8229a5160eea145b796f54317d6e659cec9b080
Best regards,
--
Krzysztof Kozlowski <krzk@kernel.org>
Hi Krzysztof, On Sat, 21 Mar 2026 at 14:18, Krzysztof Kozlowski <krzk@kernel.org> wrote: > > > On Wed, 18 Mar 2026 15:27:45 +0000, André Draszik wrote: > > This series adds support for the power domains on Google GS101. > > > > There are a few differences compared to SoCs already supported by this > > driver: > > * register access does not work via plain ioremap() / readl() / > > writel(). > > Instead, the regmap created by the PMU driver must be used (which > > uses Arm SMCC calls under the hood). > > * DTZPC: a call needs to be made before and after power domain off/on, > > to inform the EL3 firmware of the request. > > * power domains can and are fed by a regulator rail and therefore > > regulator control needed be implemented. > > > > [...] > > Applied, thanks! > > [01/10] dt-bindings: soc: google: add google,gs101-dtzpc > https://git.kernel.org/krzk/linux/c/10084aeadadfab72648f6ed1cc78f7cd87b861ba > [03/10] dt-bindings: soc: samsung: exynos-pmu: move gs101-pmu into separate binding > https://git.kernel.org/krzk/linux/c/3ec3c42b426fe5e2b48ff19c551dec50bc78788c > [04/10] dt-bindings: soc: google: gs101-pmu: allow power domains as children > https://git.kernel.org/krzk/linux/c/c8229a5160eea145b796f54317d6e659cec9b080 > > Best regards, Usually I pick up the power-domain related changes for the DT bindings and host them via an immutable branch called "dt". If needed, SOC maintainers can pull it to apply/test the corresponding DTS changes. That said, I am open to whatever you think is best here. Perhaps it's easier if you can drop the DT patches and provide your acks instead or if you can share them via an immutable branch for me to pull? Kind regards Uffe > -- > Krzysztof Kozlowski <krzk@kernel.org> >
On 23/03/2026 12:13, Ulf Hansson wrote: > Hi Krzysztof, > > On Sat, 21 Mar 2026 at 14:18, Krzysztof Kozlowski <krzk@kernel.org> wrote: >> >> >> On Wed, 18 Mar 2026 15:27:45 +0000, André Draszik wrote: >>> This series adds support for the power domains on Google GS101. >>> >>> There are a few differences compared to SoCs already supported by this >>> driver: >>> * register access does not work via plain ioremap() / readl() / >>> writel(). >>> Instead, the regmap created by the PMU driver must be used (which >>> uses Arm SMCC calls under the hood). >>> * DTZPC: a call needs to be made before and after power domain off/on, >>> to inform the EL3 firmware of the request. >>> * power domains can and are fed by a regulator rail and therefore >>> regulator control needed be implemented. >>> >>> [...] >> >> Applied, thanks! >> >> [01/10] dt-bindings: soc: google: add google,gs101-dtzpc >> https://git.kernel.org/krzk/linux/c/10084aeadadfab72648f6ed1cc78f7cd87b861ba >> [03/10] dt-bindings: soc: samsung: exynos-pmu: move gs101-pmu into separate binding >> https://git.kernel.org/krzk/linux/c/3ec3c42b426fe5e2b48ff19c551dec50bc78788c >> [04/10] dt-bindings: soc: google: gs101-pmu: allow power domains as children >> https://git.kernel.org/krzk/linux/c/c8229a5160eea145b796f54317d6e659cec9b080 >> >> Best regards, > > Usually I pick up the power-domain related changes for the DT bindings > and host them via an immutable branch called "dt". If needed, SOC > maintainers can pull it to apply/test the corresponding DTS changes. > > That said, I am open to whatever you think is best here. Perhaps it's > easier if you can drop the DT patches and provide your acks instead or > if you can share them via an immutable branch for me to pull? I did not pick up any pmdomain binding patches. I picked up only soc and according to cover letter there are no dependencies between anything here. Best regards, Krzysztof
On Mon, 30 Mar 2026 at 11:54, Krzysztof Kozlowski <krzk@kernel.org> wrote: > > On 23/03/2026 12:13, Ulf Hansson wrote: > > Hi Krzysztof, > > > > On Sat, 21 Mar 2026 at 14:18, Krzysztof Kozlowski <krzk@kernel.org> wrote: > >> > >> > >> On Wed, 18 Mar 2026 15:27:45 +0000, André Draszik wrote: > >>> This series adds support for the power domains on Google GS101. > >>> > >>> There are a few differences compared to SoCs already supported by this > >>> driver: > >>> * register access does not work via plain ioremap() / readl() / > >>> writel(). > >>> Instead, the regmap created by the PMU driver must be used (which > >>> uses Arm SMCC calls under the hood). > >>> * DTZPC: a call needs to be made before and after power domain off/on, > >>> to inform the EL3 firmware of the request. > >>> * power domains can and are fed by a regulator rail and therefore > >>> regulator control needed be implemented. > >>> > >>> [...] > >> > >> Applied, thanks! > >> > >> [01/10] dt-bindings: soc: google: add google,gs101-dtzpc > >> https://git.kernel.org/krzk/linux/c/10084aeadadfab72648f6ed1cc78f7cd87b861ba > >> [03/10] dt-bindings: soc: samsung: exynos-pmu: move gs101-pmu into separate binding > >> https://git.kernel.org/krzk/linux/c/3ec3c42b426fe5e2b48ff19c551dec50bc78788c > >> [04/10] dt-bindings: soc: google: gs101-pmu: allow power domains as children > >> https://git.kernel.org/krzk/linux/c/c8229a5160eea145b796f54317d6e659cec9b080 > >> > >> Best regards, > > > > Usually I pick up the power-domain related changes for the DT bindings > > and host them via an immutable branch called "dt". If needed, SOC > > maintainers can pull it to apply/test the corresponding DTS changes. > > > > That said, I am open to whatever you think is best here. Perhaps it's > > easier if you can drop the DT patches and provide your acks instead or > > if you can share them via an immutable branch for me to pull? > > > I did not pick up any pmdomain binding patches. I picked up only soc and > according to cover letter there are no dependencies between anything here. As I understand it, they are all related and some even depend on each other. I think keeping all four DT patches together makes sense. Although, as I said, if you think it's best to funnel them through your tree, please do and then share them via an immutable branch, so I can apply the pmdomain driver changes. Kind regards Uffe
On 30/03/2026 12:13, Ulf Hansson wrote: > On Mon, 30 Mar 2026 at 11:54, Krzysztof Kozlowski <krzk@kernel.org> wrote: >> >> On 23/03/2026 12:13, Ulf Hansson wrote: >>> Hi Krzysztof, >>> >>> On Sat, 21 Mar 2026 at 14:18, Krzysztof Kozlowski <krzk@kernel.org> wrote: >>>> >>>> >>>> On Wed, 18 Mar 2026 15:27:45 +0000, André Draszik wrote: >>>>> This series adds support for the power domains on Google GS101. >>>>> >>>>> There are a few differences compared to SoCs already supported by this >>>>> driver: >>>>> * register access does not work via plain ioremap() / readl() / >>>>> writel(). >>>>> Instead, the regmap created by the PMU driver must be used (which >>>>> uses Arm SMCC calls under the hood). >>>>> * DTZPC: a call needs to be made before and after power domain off/on, >>>>> to inform the EL3 firmware of the request. >>>>> * power domains can and are fed by a regulator rail and therefore >>>>> regulator control needed be implemented. >>>>> >>>>> [...] >>>> >>>> Applied, thanks! >>>> >>>> [01/10] dt-bindings: soc: google: add google,gs101-dtzpc >>>> https://git.kernel.org/krzk/linux/c/10084aeadadfab72648f6ed1cc78f7cd87b861ba >>>> [03/10] dt-bindings: soc: samsung: exynos-pmu: move gs101-pmu into separate binding >>>> https://git.kernel.org/krzk/linux/c/3ec3c42b426fe5e2b48ff19c551dec50bc78788c >>>> [04/10] dt-bindings: soc: google: gs101-pmu: allow power domains as children >>>> https://git.kernel.org/krzk/linux/c/c8229a5160eea145b796f54317d6e659cec9b080 >>>> >>>> Best regards, >>> >>> Usually I pick up the power-domain related changes for the DT bindings >>> and host them via an immutable branch called "dt". If needed, SOC >>> maintainers can pull it to apply/test the corresponding DTS changes. >>> >>> That said, I am open to whatever you think is best here. Perhaps it's >>> easier if you can drop the DT patches and provide your acks instead or >>> if you can share them via an immutable branch for me to pull? >> >> >> I did not pick up any pmdomain binding patches. I picked up only soc and >> according to cover letter there are no dependencies between anything here. > > As I understand it, they are all related and some even depend on each I raised exactly that questions but no answers. > other. I think keeping all four DT patches together makes sense. Why? What is the dependency? > > Although, as I said, if you think it's best to funnel them through > your tree, please do and then share them via an immutable branch, so I > can apply the pmdomain driver changes. soc must go via my tree, but there is no reason to take the pmdomain binding patch. So I did not take. But anyway, I just noticed that I dropped everything: this introduces new warnings which were nowhere addressed or explained. So regardless how this should go, please do not apply anything - it's broken and author is silent. Best regards, Krzysztof
On Mon, 30 Mar 2026 at 12:17, Krzysztof Kozlowski <krzk@kernel.org> wrote: > > On 30/03/2026 12:13, Ulf Hansson wrote: > > On Mon, 30 Mar 2026 at 11:54, Krzysztof Kozlowski <krzk@kernel.org> wrote: > >> > >> On 23/03/2026 12:13, Ulf Hansson wrote: > >>> Hi Krzysztof, > >>> > >>> On Sat, 21 Mar 2026 at 14:18, Krzysztof Kozlowski <krzk@kernel.org> wrote: > >>>> > >>>> > >>>> On Wed, 18 Mar 2026 15:27:45 +0000, André Draszik wrote: > >>>>> This series adds support for the power domains on Google GS101. > >>>>> > >>>>> There are a few differences compared to SoCs already supported by this > >>>>> driver: > >>>>> * register access does not work via plain ioremap() / readl() / > >>>>> writel(). > >>>>> Instead, the regmap created by the PMU driver must be used (which > >>>>> uses Arm SMCC calls under the hood). > >>>>> * DTZPC: a call needs to be made before and after power domain off/on, > >>>>> to inform the EL3 firmware of the request. > >>>>> * power domains can and are fed by a regulator rail and therefore > >>>>> regulator control needed be implemented. > >>>>> > >>>>> [...] > >>>> > >>>> Applied, thanks! > >>>> > >>>> [01/10] dt-bindings: soc: google: add google,gs101-dtzpc > >>>> https://git.kernel.org/krzk/linux/c/10084aeadadfab72648f6ed1cc78f7cd87b861ba > >>>> [03/10] dt-bindings: soc: samsung: exynos-pmu: move gs101-pmu into separate binding > >>>> https://git.kernel.org/krzk/linux/c/3ec3c42b426fe5e2b48ff19c551dec50bc78788c > >>>> [04/10] dt-bindings: soc: google: gs101-pmu: allow power domains as children > >>>> https://git.kernel.org/krzk/linux/c/c8229a5160eea145b796f54317d6e659cec9b080 > >>>> > >>>> Best regards, > >>> > >>> Usually I pick up the power-domain related changes for the DT bindings > >>> and host them via an immutable branch called "dt". If needed, SOC > >>> maintainers can pull it to apply/test the corresponding DTS changes. > >>> > >>> That said, I am open to whatever you think is best here. Perhaps it's > >>> easier if you can drop the DT patches and provide your acks instead or > >>> if you can share them via an immutable branch for me to pull? > >> > >> > >> I did not pick up any pmdomain binding patches. I picked up only soc and > >> according to cover letter there are no dependencies between anything here. > > > > As I understand it, they are all related and some even depend on each > > I raised exactly that questions but no answers. > > > other. I think keeping all four DT patches together makes sense. > > Why? What is the dependency? I defer to André to clarify this for us. > > > > > Although, as I said, if you think it's best to funnel them through > > your tree, please do and then share them via an immutable branch, so I > > can apply the pmdomain driver changes. > > soc must go via my tree, but there is no reason to take the pmdomain > binding patch. So I did not take. Yes, they belong to soc/platform, which is common for most power-domain providers. To allow us to merge/maintain power-domain provider *driver* changes separately, we needed a way to manage the corresponding DT bindings. That's why I am hosting the immutable "dt" branch for these, which soc/platform maintainers can pull-in when they need it. Of course, doing it the other way around is also possible. Just let me know what you prefer. > > But anyway, I just noticed that I dropped everything: this introduces > new warnings which were nowhere addressed or explained. So regardless > how this should go, please do not apply anything - it's broken and > author is silent. Right, I will await your confirmation! Kind regards Uffe
On 30/03/2026 13:12, Ulf Hansson wrote: > >> >>> >>> Although, as I said, if you think it's best to funnel them through >>> your tree, please do and then share them via an immutable branch, so I >>> can apply the pmdomain driver changes. >> >> soc must go via my tree, but there is no reason to take the pmdomain >> binding patch. So I did not take. > > Yes, they belong to soc/platform, which is common for most > power-domain providers. What does belong to soc/platform? pmdomain changes? No, they do not... > > To allow us to merge/maintain power-domain provider *driver* changes > separately, we needed a way to manage the corresponding DT bindings. Nothing stops that, there is no dependency. For a week I am saying there are no dependencies. If there are, please provide any sort of argument/proof, otherwise there is nothing to do here. > That's why I am hosting the immutable "dt" branch for these, which > soc/platform maintainers can pull-in when they need it. > > Of course, doing it the other way around is also possible. Just let me > know what you prefer. Nothing like that is necessary. Best regards, Krzysztof
On Mon, 30 Mar 2026 at 13:24, Krzysztof Kozlowski <krzk@kernel.org> wrote: > > On 30/03/2026 13:12, Ulf Hansson wrote: > > > >> > >>> > >>> Although, as I said, if you think it's best to funnel them through > >>> your tree, please do and then share them via an immutable branch, so I > >>> can apply the pmdomain driver changes. > >> > >> soc must go via my tree, but there is no reason to take the pmdomain > >> binding patch. So I did not take. > > > > Yes, they belong to soc/platform, which is common for most > > power-domain providers. > > What does belong to soc/platform? pmdomain changes? No, they do not... I think you may have misunderstood me here. I was referring to the DT bindings that describe power domain providers. Generally speaking, these are often provided via some SOC/platform-specific hardware (like a PMU for example). > > > > > To allow us to merge/maintain power-domain provider *driver* changes > > separately, we needed a way to manage the corresponding DT bindings. > > Nothing stops that, there is no dependency. For a week I am saying there > are no dependencies. If there are, please provide any sort of > argument/proof, otherwise there is nothing to do here. > > > That's why I am hosting the immutable "dt" branch for these, which > > soc/platform maintainers can pull-in when they need it. > > > > Of course, doing it the other way around is also possible. Just let me > > know what you prefer. > > Nothing like that is necessary. Usually we want bindings to go along with their respective drivers on a subsystem basis. Both patch2 and patch4 updates DT bindings for the power-domain providers. Why shouldn't the bindings go along with the driver changes here? Kind regards Uffe
On 30/03/2026 15:30, Ulf Hansson wrote: > > Usually we want bindings to go along with their respective drivers on > a subsystem basis. > > Both patch2 and patch4 updates DT bindings for the power-domain providers. Patch 2 yes. Patch 4 not. That's why I did not take patch 2. > > Why shouldn't the bindings go along with the driver changes here? Patch #2 is pmdomain, so with pmdomain drivers thus your tree. Patch #4 is not pmdomain, so not with pmdomain drivers, so not your tree... At least I do not see any pmdomain parts in that patch #4. It's a Samsung SoC PMU driver and none of further driver patches touch that PMU driver. Best regards, Krzysztof
On Mon, 30 Mar 2026 at 15:38, Krzysztof Kozlowski <krzk@kernel.org> wrote: > > On 30/03/2026 15:30, Ulf Hansson wrote: > > > > Usually we want bindings to go along with their respective drivers on > > a subsystem basis. > > > > Both patch2 and patch4 updates DT bindings for the power-domain providers. > > Patch 2 yes. Patch 4 not. That's why I did not take patch 2. > > > > > Why shouldn't the bindings go along with the driver changes here? > > Patch #2 is pmdomain, so with pmdomain drivers thus your tree. Patch #4 > is not pmdomain, so not with pmdomain drivers, so not your tree... At > least I do not see any pmdomain parts in that patch #4. It's a Samsung > SoC PMU driver and none of further driver patches touch that PMU driver. Yes, you are right that the PMU driver isn't touched. Although, the PMU DT description added in patch3 and extended in patch4, allows power-domain providers to be described in its child nodes. Those child nodes use the same compatible string as the power-domain providers described in patch2. Kind regards Uffe
© 2016 - 2026 Red Hat, Inc.