| Message ID | 20230829213441.310655-1-ulf.hansson@linaro.org |
|---|---|
| State | New |
| Headers | show |
| Series | [GIT,PULL] ARM: SoC/genpd driver updates for v6.6 | expand |
Hi Ulf, On Thu, Aug 31, 2023 at 1:39 PM Ulf Hansson <ulf.hansson@linaro.org> wrote: > On Thu, 31 Aug 2023 at 11:33, Rafael J. Wysocki <rafael@kernel.org> wrote: > > If I may suggest something, I would call this "pmdomain" instead of > > "genpd". I don't think that /drivers/power/ is a particularly > > suitable location for it, because it doesn't really have much to do > > with power supplies and more to do with device PM. > > "pmdomain" is probably giving a reasonable good hint of what goes on > in this subsystem. This works fine for me, thanks! Sounds nice! All of this lives in <linux/pm_domain.h> (with underscore?) anyway, and "PM Domains" is the usual naming, as it covers both Power and Clock Domains. However, although I am quite familiar with genpd, I am still wondering what is the meaning of the "generic" part in the name? And what is a non-generic PM Domain? > > Also, I would move drivers/base/power/domain.c to drivers/pmdomain/ > > (and rename it to something like core.c), because it would be a better > > location for that fiile IMO. > > We could certainly do that, let's discuss it a bit more. > > Although, at this point I want to focus on the genpd providers, as to > release some of the burden from arm-soc maintainers. > > > I can also handle future pull requests for this if that's fine with everyone. > > Thanks a lot for your offer! However, if a re-route is preferred (I > think not?), this is probably better suited via arm-soc, as most > changes are going to be arm platform specific. Which brings me to the final question: what is the upstream path for changes to drivers/genpd/*/ (or whatever it's gonna be called)? Before, we sent PRs to (arm-)soc. Do you expect us to send them to you? There's usually quite some interaction between drivers/soc/reneas/ and drivers/genpd/renesas (and there are DT binding definitions), but not more than with e.g. drivers/clk/renesas/. And I just realized you moved the code and Makefiles to drivers/genpd/, but not the Kconfig symbols and logic, which still lives under drivers/soc/. So resolving that (and the name) is something that should be resolved sooner rather than later... Thanks! Gr{oetje,eeting}s, Geert
Hi Ulf, On Mon, Sep 11, 2023 at 1:28 PM Ulf Hansson <ulf.hansson@linaro.org> wrote: > On Mon, 11 Sept 2023 at 09:52, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > On Thu, Aug 31, 2023 at 1:39 PM Ulf Hansson <ulf.hansson@linaro.org> wrote: > > > On Thu, 31 Aug 2023 at 11:33, Rafael J. Wysocki <rafael@kernel.org> wrote: > > > > If I may suggest something, I would call this "pmdomain" instead of > > > > "genpd". I don't think that /drivers/power/ is a particularly > > > > suitable location for it, because it doesn't really have much to do > > > > with power supplies and more to do with device PM. > > > > > > "pmdomain" is probably giving a reasonable good hint of what goes on > > > in this subsystem. This works fine for me, thanks! > > > > > > Also, I would move drivers/base/power/domain.c to drivers/pmdomain/ > > > > (and rename it to something like core.c), because it would be a better > > > > location for that fiile IMO. > > > > > > We could certainly do that, let's discuss it a bit more. > > > > > > Although, at this point I want to focus on the genpd providers, as to > > > release some of the burden from arm-soc maintainers. > > > > > > > I can also handle future pull requests for this if that's fine with everyone. > > > > > > Thanks a lot for your offer! However, if a re-route is preferred (I > > > think not?), this is probably better suited via arm-soc, as most > > > changes are going to be arm platform specific. > > > > Which brings me to the final question: what is the upstream path > > for changes to drivers/genpd/*/ (or whatever it's gonna be called)? > > Before, we sent PRs to (arm-)soc. Do you expect us to send them to > > you? There's usually quite some interaction between drivers/soc/reneas/ > > and drivers/genpd/renesas (and there are DT binding definitions), > > but not more than with e.g. drivers/clk/renesas/. > > I would be happy to pick this up and funnel this via my new genpd > tree. As long as it's coupled with changes affecting "genpd > providers", of course. > > I can certainly also collect patches directly from the > mailing-list/patch-tracker too. Whatever works for you the best. Of > course, in that case I need your acks before I pick up the relevant > patches. > > If we need "immutable" branches, let's discuss that on a case by case basis. At least for Renesas SoCs, every new SoC comes with a DT binding definitions file under include/dt-bindings/power/, to be shared by genpd driver and DTS (the same is true for clocks). So PRs will work best. > > And I just realized you moved the code and Makefiles to drivers/genpd/, > > but not the Kconfig symbols and logic, which still lives under > > drivers/soc/. So resolving that (and the name) is something that > > should be resolved sooner rather than later... > > In regards to the name, I am relying on input from Linus to make a > final decision before I send a patch. In regards to this, I have also > started working on a documentation patch for genpd. It needs some more > polishing before I can send it though. > > When it comes to the Kconfig move, I will send out a series for it, this week. OK. Thanks! Gr{oetje,eeting}s, Geert
On Mon, 11 Sept 2023 at 13:48, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > Hi Ulf, > > On Mon, Sep 11, 2023 at 1:28 PM Ulf Hansson <ulf.hansson@linaro.org> wrote: > > On Mon, 11 Sept 2023 at 09:52, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > > On Thu, Aug 31, 2023 at 1:39 PM Ulf Hansson <ulf.hansson@linaro.org> wrote: > > > > On Thu, 31 Aug 2023 at 11:33, Rafael J. Wysocki <rafael@kernel.org> wrote: > > > > > If I may suggest something, I would call this "pmdomain" instead of > > > > > "genpd". I don't think that /drivers/power/ is a particularly > > > > > suitable location for it, because it doesn't really have much to do > > > > > with power supplies and more to do with device PM. > > > > > > > > "pmdomain" is probably giving a reasonable good hint of what goes on > > > > in this subsystem. This works fine for me, thanks! > > > > > > > > Also, I would move drivers/base/power/domain.c to drivers/pmdomain/ > > > > > (and rename it to something like core.c), because it would be a better > > > > > location for that fiile IMO. > > > > > > > > We could certainly do that, let's discuss it a bit more. > > > > > > > > Although, at this point I want to focus on the genpd providers, as to > > > > release some of the burden from arm-soc maintainers. > > > > > > > > > I can also handle future pull requests for this if that's fine with everyone. > > > > > > > > Thanks a lot for your offer! However, if a re-route is preferred (I > > > > think not?), this is probably better suited via arm-soc, as most > > > > changes are going to be arm platform specific. > > > > > > Which brings me to the final question: what is the upstream path > > > for changes to drivers/genpd/*/ (or whatever it's gonna be called)? > > > Before, we sent PRs to (arm-)soc. Do you expect us to send them to > > > you? There's usually quite some interaction between drivers/soc/reneas/ > > > and drivers/genpd/renesas (and there are DT binding definitions), > > > but not more than with e.g. drivers/clk/renesas/. > > > > I would be happy to pick this up and funnel this via my new genpd > > tree. As long as it's coupled with changes affecting "genpd > > providers", of course. > > > > I can certainly also collect patches directly from the > > mailing-list/patch-tracker too. Whatever works for you the best. Of > > course, in that case I need your acks before I pick up the relevant > > patches. > > > > If we need "immutable" branches, let's discuss that on a case by case basis. > > At least for Renesas SoCs, every new SoC comes with a DT binding > definitions file under include/dt-bindings/power/, to be shared by genpd > driver and DTS (the same is true for clocks). So PRs will work best. Good point! And Neil pointed out this too [1]. I am going to host an immutable branch for the dt bindings that you can pull in. Would that be a better option for you? [...] Kind regards Uffe [1] https://lore.kernel.org/lkml/4303c141-30df-4a2b-aba7-f11a98db9941@linaro.org/
Hi Ulf, On Mon, Sep 11, 2023 at 2:07 PM Ulf Hansson <ulf.hansson@linaro.org> wrote: > On Mon, 11 Sept 2023 at 13:48, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > On Mon, Sep 11, 2023 at 1:28 PM Ulf Hansson <ulf.hansson@linaro.org> wrote: > > > On Mon, 11 Sept 2023 at 09:52, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > > > On Thu, Aug 31, 2023 at 1:39 PM Ulf Hansson <ulf.hansson@linaro.org> wrote: > > > > > On Thu, 31 Aug 2023 at 11:33, Rafael J. Wysocki <rafael@kernel.org> wrote: > > > > > > If I may suggest something, I would call this "pmdomain" instead of > > > > > > "genpd". I don't think that /drivers/power/ is a particularly > > > > > > suitable location for it, because it doesn't really have much to do > > > > > > with power supplies and more to do with device PM. > > > > > > > > > > "pmdomain" is probably giving a reasonable good hint of what goes on > > > > > in this subsystem. This works fine for me, thanks! > > > > > > > > > > Also, I would move drivers/base/power/domain.c to drivers/pmdomain/ > > > > > > (and rename it to something like core.c), because it would be a better > > > > > > location for that fiile IMO. > > > > > > > > > > We could certainly do that, let's discuss it a bit more. > > > > > > > > > > Although, at this point I want to focus on the genpd providers, as to > > > > > release some of the burden from arm-soc maintainers. > > > > > > > > > > > I can also handle future pull requests for this if that's fine with everyone. > > > > > > > > > > Thanks a lot for your offer! However, if a re-route is preferred (I > > > > > think not?), this is probably better suited via arm-soc, as most > > > > > changes are going to be arm platform specific. > > > > > > > > Which brings me to the final question: what is the upstream path > > > > for changes to drivers/genpd/*/ (or whatever it's gonna be called)? > > > > Before, we sent PRs to (arm-)soc. Do you expect us to send them to > > > > you? There's usually quite some interaction between drivers/soc/reneas/ > > > > and drivers/genpd/renesas (and there are DT binding definitions), > > > > but not more than with e.g. drivers/clk/renesas/. > > > > > > I would be happy to pick this up and funnel this via my new genpd > > > tree. As long as it's coupled with changes affecting "genpd > > > providers", of course. > > > > > > I can certainly also collect patches directly from the > > > mailing-list/patch-tracker too. Whatever works for you the best. Of > > > course, in that case I need your acks before I pick up the relevant > > > patches. > > > > > > If we need "immutable" branches, let's discuss that on a case by case basis. > > > > At least for Renesas SoCs, every new SoC comes with a DT binding > > definitions file under include/dt-bindings/power/, to be shared by genpd > > driver and DTS (the same is true for clocks). So PRs will work best. > > Good point! And Neil pointed out this too [1]. > > I am going to host an immutable branch for the dt bindings that you > can pull in. Would that be a better option for you? Yes, that would work for me, too. Can I conclude you prefer to take patches over PRs? Gr{oetje,eeting}s, Geert
On Mon, 11 Sept 2023 at 15:06, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > Hi Ulf, > > On Mon, Sep 11, 2023 at 2:07 PM Ulf Hansson <ulf.hansson@linaro.org> wrote: > > On Mon, 11 Sept 2023 at 13:48, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > > On Mon, Sep 11, 2023 at 1:28 PM Ulf Hansson <ulf.hansson@linaro.org> wrote: > > > > On Mon, 11 Sept 2023 at 09:52, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > > > > On Thu, Aug 31, 2023 at 1:39 PM Ulf Hansson <ulf.hansson@linaro.org> wrote: > > > > > > On Thu, 31 Aug 2023 at 11:33, Rafael J. Wysocki <rafael@kernel.org> wrote: > > > > > > > If I may suggest something, I would call this "pmdomain" instead of > > > > > > > "genpd". I don't think that /drivers/power/ is a particularly > > > > > > > suitable location for it, because it doesn't really have much to do > > > > > > > with power supplies and more to do with device PM. > > > > > > > > > > > > "pmdomain" is probably giving a reasonable good hint of what goes on > > > > > > in this subsystem. This works fine for me, thanks! > > > > > > > > > > > > Also, I would move drivers/base/power/domain.c to drivers/pmdomain/ > > > > > > > (and rename it to something like core.c), because it would be a better > > > > > > > location for that fiile IMO. > > > > > > > > > > > > We could certainly do that, let's discuss it a bit more. > > > > > > > > > > > > Although, at this point I want to focus on the genpd providers, as to > > > > > > release some of the burden from arm-soc maintainers. > > > > > > > > > > > > > I can also handle future pull requests for this if that's fine with everyone. > > > > > > > > > > > > Thanks a lot for your offer! However, if a re-route is preferred (I > > > > > > think not?), this is probably better suited via arm-soc, as most > > > > > > changes are going to be arm platform specific. > > > > > > > > > > Which brings me to the final question: what is the upstream path > > > > > for changes to drivers/genpd/*/ (or whatever it's gonna be called)? > > > > > Before, we sent PRs to (arm-)soc. Do you expect us to send them to > > > > > you? There's usually quite some interaction between drivers/soc/reneas/ > > > > > and drivers/genpd/renesas (and there are DT binding definitions), > > > > > but not more than with e.g. drivers/clk/renesas/. > > > > > > > > I would be happy to pick this up and funnel this via my new genpd > > > > tree. As long as it's coupled with changes affecting "genpd > > > > providers", of course. > > > > > > > > I can certainly also collect patches directly from the > > > > mailing-list/patch-tracker too. Whatever works for you the best. Of > > > > course, in that case I need your acks before I pick up the relevant > > > > patches. > > > > > > > > If we need "immutable" branches, let's discuss that on a case by case basis. > > > > > > At least for Renesas SoCs, every new SoC comes with a DT binding > > > definitions file under include/dt-bindings/power/, to be shared by genpd > > > driver and DTS (the same is true for clocks). So PRs will work best. > > > > Good point! And Neil pointed out this too [1]. > > > > I am going to host an immutable branch for the dt bindings that you > > can pull in. Would that be a better option for you? > > Yes, that would work for me, too. > Can I conclude you prefer to take patches over PRs? In general, yes. But, I am fine with both options, as long as it works for you too! Kind regards Uffe
On Mon, Sep 11, 2023, at 13:28, Ulf Hansson wrote: > On Mon, 11 Sept 2023 at 09:52, Geert Uytterhoeven <geert@linux-m68k.org> wrote: >> >> And I just realized you moved the code and Makefiles to drivers/genpd/, >> but not the Kconfig symbols and logic, which still lives under >> drivers/soc/. So resolving that (and the name) is something that >> should be resolved sooner rather than later... > > In regards to the name, I am relying on input from Linus to make a > final decision before I send a patch. In regards to this, I have also > started working on a documentation patch for genpd. It needs some more > polishing before I can send it though. I'm fairly sure that Linus was instead waiting for you to send a patch or pull request for the rename. Please just pick a name that you like and that Linus hasn't already objected to and send it so the rename makes it into -rc2 for others to base on. If anyone has objections to the new name, you'll find out about it then, but I think we trust your judgement here. Arnd
On Tue, 12 Sept 2023 at 15:58, Arnd Bergmann <arnd@arndb.de> wrote: > > On Mon, Sep 11, 2023, at 13:28, Ulf Hansson wrote: > > On Mon, 11 Sept 2023 at 09:52, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > >> > >> And I just realized you moved the code and Makefiles to drivers/genpd/, > >> but not the Kconfig symbols and logic, which still lives under > >> drivers/soc/. So resolving that (and the name) is something that > >> should be resolved sooner rather than later... > > > > In regards to the name, I am relying on input from Linus to make a > > final decision before I send a patch. In regards to this, I have also > > started working on a documentation patch for genpd. It needs some more > > polishing before I can send it though. > > I'm fairly sure that Linus was instead waiting for you to send > a patch or pull request for the rename. Please just pick a name > that you like and that Linus hasn't already objected to and send > it so the rename makes it into -rc2 for others to base on. > > If anyone has objections to the new name, you'll find out about > it then, but I think we trust your judgement here. > > Arnd Alright. One can interpret silence differently. :-) Anyway, I have followed your advice and submitted a patch. I have queued up a couple of patches for "genpd" already, but it's still easy to rebase them after a rename, so not a big deal for me at the moment. Kind regards Uffe
Hi Linus, Here's a pull-request that introduces the genpd provider subsystem. Most of the changes have been shared via an immutable branch/tag, which has been pulled in by Arnd Bergmann into the soc tree. However, as I have also queued up a couple of additional changes on top, I am sending this pull request for you. The changes have been tested in linux-next via git.kernel.org/pub/scm/linux/kernel/git/ulfh/linux-pm.git next|fixes Beyond v6.6-rc1, I am planning to keep sending pull-requests with fixes and new material for new genpd provider subsystem to you. If you prefer another route, please let us know. Kind regards Ulf Hansson The following changes since commit 06c2afb862f9da8dc5efa4b6076a0e48c3fbaaa5: Linux 6.5-rc1 (2023-07-09 13:53:13 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/linux-pm.git tags/genpd-v6.6 for you to fetch changes up to 5e536362f6ab97f709c07bfda962a7bb036c2563: genpd: ti: Use for_each_node_with_property() simplify code logic (2023-08-25 12:04:57 +0200) ---------------------------------------------------------------- This pull-request adds a new subsystem for genpd providers in drivers/genpd and starts moving some of the corresponding code in there. We have currently ~60 users of the genpd provider interface, which are sprinkled across various subsystems. To release some burden from the soc maintainers (Arnd Bergmann, etc) in particular, but also to gain a better overall view of what goes on in the area, I will help out with maintenance. ---------------------------------------------------------------- Arnd Bergmann (2): soc: starfive: remove stale Makefile entry genpd: move owl-sps-helper.c from drivers/soc Lukas Bulwahn (1): MAINTAINERS: adjust file entry in STARFIVE JH71XX PMU CONTROLLER DRIVER Peng Fan (7): genpd: Makefile: build imx genpd: imx: relocate scu-pd under genpd genpd: imx: scu-pd: enlarge PD range genpd: imx: scu-pd: add more PDs genpd: imx: scu-pd: do not power off console if no_console_suspend genpd: imx: scu-pd: Suppress bind attrs genpd: imx: scu-pd: initialize is_off according to HW state Rob Herring (1): genpd: Explicitly include correct DT includes Ulf Hansson (18): genpd: Create a new subsystem directory to host genpd providers soc: actions: Move power-domain driver to the genpd dir soc: amlogic: Move power-domain drivers to the genpd dir soc: apple: Move power-domain driver to the genpd dir soc: bcm: Move power-domain drivers to the genpd dir soc: imx: Move power-domain drivers to the genpd dir soc: mediatek: Move power-domain drivers to the genpd dir soc: qcom: Move power-domain drivers to the genpd dir soc: renesas: Move power-domain drivers to the genpd dir soc: rockchip: Mover power-domain driver to the genpd dir soc: samsung: Move power-domain driver to the genpd dir soc: starfive: Move the power-domain driver to the genpd dir soc: sunxi: Move power-domain driver to the genpd dir soc: tegra: Move powergate-bpmp driver to the genpd dir soc: ti: Mover power-domain drivers to the genpd dir soc: xilinx: Move power-domain driver to the genpd dir ARM: ux500: Convert power-domain code into a regular platform driver ARM: ux500: Move power-domain driver to the genpd dir Zhang Zekun (1): genpd: ti: Use for_each_node_with_property() simplify code logic MAINTAINERS | 22 +++- arch/arm/mach-ux500/Makefile | 1 - arch/arm/mach-ux500/cpu-db8500.c | 5 - arch/arm/mach-ux500/pm_domains.h | 17 --- drivers/Makefile | 1 + drivers/firmware/imx/Makefile | 1 - drivers/genpd/Makefile | 17 +++ drivers/genpd/actions/Makefile | 3 + drivers/{soc => genpd}/actions/owl-sps-helper.c | 0 drivers/{soc => genpd}/actions/owl-sps.c | 0 drivers/genpd/amlogic/Makefile | 4 + drivers/{soc => genpd}/amlogic/meson-ee-pwrc.c | 0 drivers/{soc => genpd}/amlogic/meson-gx-pwrc-vpu.c | 0 drivers/{soc => genpd}/amlogic/meson-secure-pwrc.c | 0 drivers/genpd/apple/Makefile | 2 + .../apple/pmgr-pwrstate.c} | 0 drivers/genpd/bcm/Makefile | 5 + drivers/{soc/bcm/bcm63xx => genpd/bcm}/bcm-pmb.c | 0 drivers/{soc => genpd}/bcm/bcm2835-power.c | 0 .../{soc/bcm/bcm63xx => genpd/bcm}/bcm63xx-power.c | 0 drivers/{soc => genpd}/bcm/raspberrypi-power.c | 0 drivers/genpd/imx/Makefile | 8 ++ drivers/{soc => genpd}/imx/gpc.c | 0 drivers/{soc => genpd}/imx/gpcv2.c | 0 drivers/{soc => genpd}/imx/imx8m-blk-ctrl.c | 0 drivers/{soc => genpd}/imx/imx8mp-blk-ctrl.c | 0 drivers/{soc => genpd}/imx/imx93-blk-ctrl.c | 0 drivers/{soc => genpd}/imx/imx93-pd.c | 0 drivers/{firmware => genpd}/imx/scu-pd.c | 138 +++++++++++++++++++-- drivers/genpd/mediatek/Makefile | 3 + .../{soc => genpd}/mediatek/mt6795-pm-domains.h | 0 .../{soc => genpd}/mediatek/mt8167-pm-domains.h | 0 .../{soc => genpd}/mediatek/mt8173-pm-domains.h | 0 .../{soc => genpd}/mediatek/mt8183-pm-domains.h | 0 .../{soc => genpd}/mediatek/mt8186-pm-domains.h | 0 .../{soc => genpd}/mediatek/mt8188-pm-domains.h | 0 .../{soc => genpd}/mediatek/mt8192-pm-domains.h | 0 .../{soc => genpd}/mediatek/mt8195-pm-domains.h | 0 drivers/{soc => genpd}/mediatek/mtk-pm-domains.c | 2 +- drivers/{soc => genpd}/mediatek/mtk-pm-domains.h | 0 drivers/{soc => genpd}/mediatek/mtk-scpsys.c | 2 +- drivers/genpd/qcom/Makefile | 4 + drivers/{soc => genpd}/qcom/cpr.c | 0 drivers/{soc => genpd}/qcom/rpmhpd.c | 0 drivers/{soc => genpd}/qcom/rpmpd.c | 0 drivers/genpd/renesas/Makefile | 30 +++++ drivers/{soc => genpd}/renesas/r8a7742-sysc.c | 0 drivers/{soc => genpd}/renesas/r8a7743-sysc.c | 0 drivers/{soc => genpd}/renesas/r8a7745-sysc.c | 0 drivers/{soc => genpd}/renesas/r8a77470-sysc.c | 0 drivers/{soc => genpd}/renesas/r8a774a1-sysc.c | 0 drivers/{soc => genpd}/renesas/r8a774b1-sysc.c | 0 drivers/{soc => genpd}/renesas/r8a774c0-sysc.c | 0 drivers/{soc => genpd}/renesas/r8a774e1-sysc.c | 0 drivers/{soc => genpd}/renesas/r8a7779-sysc.c | 0 drivers/{soc => genpd}/renesas/r8a7790-sysc.c | 0 drivers/{soc => genpd}/renesas/r8a7791-sysc.c | 0 drivers/{soc => genpd}/renesas/r8a7792-sysc.c | 0 drivers/{soc => genpd}/renesas/r8a7794-sysc.c | 0 drivers/{soc => genpd}/renesas/r8a7795-sysc.c | 0 drivers/{soc => genpd}/renesas/r8a7796-sysc.c | 0 drivers/{soc => genpd}/renesas/r8a77965-sysc.c | 0 drivers/{soc => genpd}/renesas/r8a77970-sysc.c | 0 drivers/{soc => genpd}/renesas/r8a77980-sysc.c | 0 drivers/{soc => genpd}/renesas/r8a77990-sysc.c | 0 drivers/{soc => genpd}/renesas/r8a77995-sysc.c | 0 drivers/{soc => genpd}/renesas/r8a779a0-sysc.c | 0 drivers/{soc => genpd}/renesas/r8a779f0-sysc.c | 0 drivers/{soc => genpd}/renesas/r8a779g0-sysc.c | 0 drivers/{soc => genpd}/renesas/rcar-gen4-sysc.c | 0 drivers/{soc => genpd}/renesas/rcar-gen4-sysc.h | 0 drivers/{soc => genpd}/renesas/rcar-sysc.c | 0 drivers/{soc => genpd}/renesas/rcar-sysc.h | 0 drivers/{soc => genpd}/renesas/rmobile-sysc.c | 0 drivers/genpd/rockchip/Makefile | 2 + .../pm_domains.c => genpd/rockchip/pm-domains.c} | 0 drivers/genpd/samsung/Makefile | 2 + .../samsung/exynos-pm-domains.c} | 0 drivers/genpd/st/Makefile | 2 + .../genpd/st/ste-ux500-pm-domain.c | 25 +++- drivers/genpd/starfive/Makefile | 2 + .../jh71xx_pmu.c => genpd/starfive/jh71xx-pmu.c} | 0 drivers/genpd/sunxi/Makefile | 2 + drivers/{soc => genpd}/sunxi/sun20i-ppu.c | 2 +- drivers/genpd/tegra/Makefile | 2 + drivers/{soc => genpd}/tegra/powergate-bpmp.c | 0 drivers/genpd/ti/Makefile | 3 + drivers/{soc => genpd}/ti/omap_prm.c | 0 drivers/{soc => genpd}/ti/ti_sci_pm_domains.c | 8 +- drivers/genpd/xilinx/Makefile | 2 + .../xilinx/zynqmp-pm-domains.c} | 0 drivers/soc/Makefile | 2 - drivers/soc/actions/Makefile | 4 - drivers/soc/amlogic/Makefile | 3 - drivers/soc/apple/Makefile | 2 - drivers/soc/bcm/Kconfig | 22 +++- drivers/soc/bcm/Makefile | 3 - drivers/soc/bcm/bcm63xx/Kconfig | 21 ---- drivers/soc/bcm/bcm63xx/Makefile | 3 - drivers/soc/imx/Makefile | 7 +- drivers/soc/mediatek/Makefile | 2 - drivers/soc/qcom/Makefile | 3 - drivers/soc/renesas/Makefile | 27 ---- drivers/soc/rockchip/Makefile | 1 - drivers/soc/samsung/Makefile | 1 - drivers/soc/starfive/Makefile | 3 - drivers/soc/sunxi/Makefile | 1 - drivers/soc/tegra/Makefile | 1 - drivers/soc/ti/Makefile | 2 - drivers/soc/xilinx/Makefile | 1 - 110 files changed, 288 insertions(+), 138 deletions(-) delete mode 100644 arch/arm/mach-ux500/pm_domains.h create mode 100644 drivers/genpd/Makefile create mode 100644 drivers/genpd/actions/Makefile rename drivers/{soc => genpd}/actions/owl-sps-helper.c (100%) rename drivers/{soc => genpd}/actions/owl-sps.c (100%) create mode 100644 drivers/genpd/amlogic/Makefile rename drivers/{soc => genpd}/amlogic/meson-ee-pwrc.c (100%) rename drivers/{soc => genpd}/amlogic/meson-gx-pwrc-vpu.c (100%) rename drivers/{soc => genpd}/amlogic/meson-secure-pwrc.c (100%) create mode 100644 drivers/genpd/apple/Makefile rename drivers/{soc/apple/apple-pmgr-pwrstate.c => genpd/apple/pmgr-pwrstate.c} (100%) create mode 100644 drivers/genpd/bcm/Makefile rename drivers/{soc/bcm/bcm63xx => genpd/bcm}/bcm-pmb.c (100%) rename drivers/{soc => genpd}/bcm/bcm2835-power.c (100%) rename drivers/{soc/bcm/bcm63xx => genpd/bcm}/bcm63xx-power.c (100%) rename drivers/{soc => genpd}/bcm/raspberrypi-power.c (100%) create mode 100644 drivers/genpd/imx/Makefile rename drivers/{soc => genpd}/imx/gpc.c (100%) rename drivers/{soc => genpd}/imx/gpcv2.c (100%) rename drivers/{soc => genpd}/imx/imx8m-blk-ctrl.c (100%) rename drivers/{soc => genpd}/imx/imx8mp-blk-ctrl.c (100%) rename drivers/{soc => genpd}/imx/imx93-blk-ctrl.c (100%) rename drivers/{soc => genpd}/imx/imx93-pd.c (100%) rename drivers/{firmware => genpd}/imx/scu-pd.c (75%) create mode 100644 drivers/genpd/mediatek/Makefile rename drivers/{soc => genpd}/mediatek/mt6795-pm-domains.h (100%) rename drivers/{soc => genpd}/mediatek/mt8167-pm-domains.h (100%) rename drivers/{soc => genpd}/mediatek/mt8173-pm-domains.h (100%) rename drivers/{soc => genpd}/mediatek/mt8183-pm-domains.h (100%) rename drivers/{soc => genpd}/mediatek/mt8186-pm-domains.h (100%) rename drivers/{soc => genpd}/mediatek/mt8188-pm-domains.h (100%) rename drivers/{soc => genpd}/mediatek/mt8192-pm-domains.h (100%) rename drivers/{soc => genpd}/mediatek/mt8195-pm-domains.h (100%) rename drivers/{soc => genpd}/mediatek/mtk-pm-domains.c (99%) rename drivers/{soc => genpd}/mediatek/mtk-pm-domains.h (100%) rename drivers/{soc => genpd}/mediatek/mtk-scpsys.c (99%) create mode 100644 drivers/genpd/qcom/Makefile rename drivers/{soc => genpd}/qcom/cpr.c (100%) rename drivers/{soc => genpd}/qcom/rpmhpd.c (100%) rename drivers/{soc => genpd}/qcom/rpmpd.c (100%) create mode 100644 drivers/genpd/renesas/Makefile rename drivers/{soc => genpd}/renesas/r8a7742-sysc.c (100%) rename drivers/{soc => genpd}/renesas/r8a7743-sysc.c (100%) rename drivers/{soc => genpd}/renesas/r8a7745-sysc.c (100%) rename drivers/{soc => genpd}/renesas/r8a77470-sysc.c (100%) rename drivers/{soc => genpd}/renesas/r8a774a1-sysc.c (100%) rename drivers/{soc => genpd}/renesas/r8a774b1-sysc.c (100%) rename drivers/{soc => genpd}/renesas/r8a774c0-sysc.c (100%) rename drivers/{soc => genpd}/renesas/r8a774e1-sysc.c (100%) rename drivers/{soc => genpd}/renesas/r8a7779-sysc.c (100%) rename drivers/{soc => genpd}/renesas/r8a7790-sysc.c (100%) rename drivers/{soc => genpd}/renesas/r8a7791-sysc.c (100%) rename drivers/{soc => genpd}/renesas/r8a7792-sysc.c (100%) rename drivers/{soc => genpd}/renesas/r8a7794-sysc.c (100%) rename drivers/{soc => genpd}/renesas/r8a7795-sysc.c (100%) rename drivers/{soc => genpd}/renesas/r8a7796-sysc.c (100%) rename drivers/{soc => genpd}/renesas/r8a77965-sysc.c (100%) rename drivers/{soc => genpd}/renesas/r8a77970-sysc.c (100%) rename drivers/{soc => genpd}/renesas/r8a77980-sysc.c (100%) rename drivers/{soc => genpd}/renesas/r8a77990-sysc.c (100%) rename drivers/{soc => genpd}/renesas/r8a77995-sysc.c (100%) rename drivers/{soc => genpd}/renesas/r8a779a0-sysc.c (100%) rename drivers/{soc => genpd}/renesas/r8a779f0-sysc.c (100%) rename drivers/{soc => genpd}/renesas/r8a779g0-sysc.c (100%) rename drivers/{soc => genpd}/renesas/rcar-gen4-sysc.c (100%) rename drivers/{soc => genpd}/renesas/rcar-gen4-sysc.h (100%) rename drivers/{soc => genpd}/renesas/rcar-sysc.c (100%) rename drivers/{soc => genpd}/renesas/rcar-sysc.h (100%) rename drivers/{soc => genpd}/renesas/rmobile-sysc.c (100%) create mode 100644 drivers/genpd/rockchip/Makefile rename drivers/{soc/rockchip/pm_domains.c => genpd/rockchip/pm-domains.c} (100%) create mode 100644 drivers/genpd/samsung/Makefile rename drivers/{soc/samsung/pm_domains.c => genpd/samsung/exynos-pm-domains.c} (100%) create mode 100644 drivers/genpd/st/Makefile rename arch/arm/mach-ux500/pm_domains.c => drivers/genpd/st/ste-ux500-pm-domain.c (75%) create mode 100644 drivers/genpd/starfive/Makefile rename drivers/{soc/starfive/jh71xx_pmu.c => genpd/starfive/jh71xx-pmu.c} (100%) create mode 100644 drivers/genpd/sunxi/Makefile rename drivers/{soc => genpd}/sunxi/sun20i-ppu.c (99%) create mode 100644 drivers/genpd/tegra/Makefile rename drivers/{soc => genpd}/tegra/powergate-bpmp.c (100%) create mode 100644 drivers/genpd/ti/Makefile rename drivers/{soc => genpd}/ti/omap_prm.c (100%) rename drivers/{soc => genpd}/ti/ti_sci_pm_domains.c (97%) create mode 100644 drivers/genpd/xilinx/Makefile rename drivers/{soc/xilinx/zynqmp_pm_domains.c => genpd/xilinx/zynqmp-pm-domains.c} (100%) delete mode 100644 drivers/soc/actions/Makefile delete mode 100644 drivers/soc/bcm/bcm63xx/Kconfig delete mode 100644 drivers/soc/bcm/bcm63xx/Makefile delete mode 100644 drivers/soc/starfive/Makefile