The avs drivers in drivers/power/avs/* are all SoC specific drivers that
doesn't share any code. Instead they are located in a directory, mostly to keep
similar functionality together. From a maintenance point of view, it makes
better sense to collect SoC specific drivers like these, into the SoC specific
directories.
Therefore, this series moves the drivers, one by one - and in the end, it
deletes the empty avs directory.
It seems best to me, if this can be funneled via Rafael's linux-pm tree. Then
when going forward, each driver should be managed through the SoC maintainer's
trees.
Kind regards
Ulf Hansson
Ulf Hansson (4):
power: avs: qcom-cpr: Move the driver to the qcom specific drivers
power: avs: rockchip-io: Move the driver to the rockchip specific
drivers
power: avs: smartreflex Move driver to soc specific drivers
power: avs: Drop the avs directory and the corresponding Kconfig
MAINTAINERS | 6 +--
arch/arm/plat-omap/Kconfig | 2 +-
drivers/power/Kconfig | 1 -
drivers/power/Makefile | 1 -
drivers/power/avs/Kconfig | 37 -------------------
drivers/power/avs/Makefile | 4 --
drivers/soc/qcom/Kconfig | 16 ++++++++
drivers/soc/qcom/Makefile | 1 +
.../{power/avs/qcom-cpr.c => soc/qcom/cpr.c} | 0
drivers/soc/rockchip/Kconfig | 8 ++++
drivers/soc/rockchip/Makefile | 1 +
.../rockchip/io-domain.c} | 0
drivers/soc/ti/Makefile | 1 +
drivers/{power/avs => soc/ti}/smartreflex.c | 0
14 files changed, 31 insertions(+), 47 deletions(-)
delete mode 100644 drivers/power/avs/Kconfig
delete mode 100644 drivers/power/avs/Makefile
rename drivers/{power/avs/qcom-cpr.c => soc/qcom/cpr.c} (100%)
rename drivers/{power/avs/rockchip-io-domain.c => soc/rockchip/io-domain.c} (100%)
rename drivers/{power/avs => soc/ti}/smartreflex.c (100%)
--
2.25.1
The avs drivers are all SoC specific drivers that doesn't share any code.
Instead they are located in a directory, mostly to keep similar
functionality together. From a maintenance point of view, it makes better
sense to collect SoC specific drivers like these, into the SoC specific
directories.
Therefore, let's move the smartreflex driver for OMAP to the ti directory.
Cc: Nishanth Menon <[email protected]>
Cc: Aaro Koskinen <[email protected]>
Cc: Tony Lindgren <[email protected]>
Cc: [email protected]
Signed-off-by: Ulf Hansson <[email protected]>
---
MAINTAINERS | 4 ++--
arch/arm/plat-omap/Kconfig | 2 +-
drivers/power/avs/Kconfig | 12 ------------
drivers/power/avs/Makefile | 1 -
drivers/soc/ti/Makefile | 1 +
drivers/{power/avs => soc/ti}/smartreflex.c | 0
6 files changed, 4 insertions(+), 16 deletions(-)
rename drivers/{power/avs => soc/ti}/smartreflex.c (100%)
diff --git a/MAINTAINERS b/MAINTAINERS
index f51dd1944fe6..040f0506d1c6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5379,11 +5379,11 @@ F: include/linux/debugfs.h
F: include/linux/kobj*
F: lib/kobj*
-DRIVERS FOR ADAPTIVE VOLTAGE SCALING (AVS)
+DRIVERS FOR OMAP ADAPTIVE VOLTAGE SCALING (AVS)
M: Nishanth Menon <[email protected]>
L: [email protected]
S: Maintained
-F: drivers/power/avs/
+F: drivers/soc/ti/smartreflex.c
F: include/linux/power/smartreflex.h
DRM DRIVER FOR ALLWINNER DE2 AND DE3 ENGINE
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index 93fd7fc537cf..272670ef1e92 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -23,7 +23,7 @@ config OMAP_DEBUG_LEDS
config POWER_AVS_OMAP
bool "AVS(Adaptive Voltage Scaling) support for OMAP IP versions 1&2"
- depends on POWER_AVS && (ARCH_OMAP3 || ARCH_OMAP4) && PM
+ depends on (ARCH_OMAP3 || ARCH_OMAP4) && PM
select POWER_SUPPLY
help
Say Y to enable AVS(Adaptive Voltage Scaling)
diff --git a/drivers/power/avs/Kconfig b/drivers/power/avs/Kconfig
index 9dde5a7e75c9..a4e40e534e6a 100644
--- a/drivers/power/avs/Kconfig
+++ b/drivers/power/avs/Kconfig
@@ -1,13 +1 @@
# SPDX-License-Identifier: GPL-2.0-only
-menuconfig POWER_AVS
- bool "Adaptive Voltage Scaling class support"
- help
- AVS is a power management technique which finely controls the
- operating voltage of a device in order to optimize (i.e. reduce)
- its power consumption.
- At a given operating point the voltage is adapted depending on
- static factors (chip manufacturing process) and dynamic factors
- (temperature depending performance).
- AVS is also called SmartReflex on OMAP devices.
-
- Say Y here to enable Adaptive Voltage Scaling class support.
diff --git a/drivers/power/avs/Makefile b/drivers/power/avs/Makefile
index d541d436f01d..a4e40e534e6a 100644
--- a/drivers/power/avs/Makefile
+++ b/drivers/power/avs/Makefile
@@ -1,2 +1 @@
# SPDX-License-Identifier: GPL-2.0-only
-obj-$(CONFIG_POWER_AVS_OMAP) += smartreflex.o
diff --git a/drivers/soc/ti/Makefile b/drivers/soc/ti/Makefile
index 1110e5c98685..5463431ec96c 100644
--- a/drivers/soc/ti/Makefile
+++ b/drivers/soc/ti/Makefile
@@ -12,3 +12,4 @@ obj-$(CONFIG_TI_SCI_PM_DOMAINS) += ti_sci_pm_domains.o
obj-$(CONFIG_TI_SCI_INTA_MSI_DOMAIN) += ti_sci_inta_msi.o
obj-$(CONFIG_TI_K3_RINGACC) += k3-ringacc.o
obj-$(CONFIG_TI_K3_SOCINFO) += k3-socinfo.o
+obj-$(CONFIG_POWER_AVS_OMAP) += smartreflex.o
diff --git a/drivers/power/avs/smartreflex.c b/drivers/soc/ti/smartreflex.c
similarity index 100%
rename from drivers/power/avs/smartreflex.c
rename to drivers/soc/ti/smartreflex.c
--
2.25.1
The avs drivers are all SoC specific drivers that doesn't share any code.
Instead they are located in a directory, mostly to keep similar
functionality together. From a maintenance point of view, it makes better
sense to collect SoC specific drivers like these, into the SoC specific
directories.
Therefore, let's move the rockchip-io driver to the rockchip directory.
Cc: Heiko Stuebner <[email protected]>
Cc: [email protected]
Signed-off-by: Ulf Hansson <[email protected]>
---
drivers/power/avs/Kconfig | 8 --------
drivers/power/avs/Makefile | 1 -
drivers/soc/rockchip/Kconfig | 8 ++++++++
drivers/soc/rockchip/Makefile | 1 +
.../avs/rockchip-io-domain.c => soc/rockchip/io-domain.c} | 0
5 files changed, 9 insertions(+), 9 deletions(-)
rename drivers/{power/avs/rockchip-io-domain.c => soc/rockchip/io-domain.c} (100%)
diff --git a/drivers/power/avs/Kconfig b/drivers/power/avs/Kconfig
index 089b6244b716..9dde5a7e75c9 100644
--- a/drivers/power/avs/Kconfig
+++ b/drivers/power/avs/Kconfig
@@ -11,11 +11,3 @@ menuconfig POWER_AVS
AVS is also called SmartReflex on OMAP devices.
Say Y here to enable Adaptive Voltage Scaling class support.
-
-config ROCKCHIP_IODOMAIN
- tristate "Rockchip IO domain support"
- depends on POWER_AVS && ARCH_ROCKCHIP && OF
- help
- Say y here to enable support io domains on Rockchip SoCs. It is
- necessary for the io domain setting of the SoC to match the
- voltage supplied by the regulators.
diff --git a/drivers/power/avs/Makefile b/drivers/power/avs/Makefile
index a1b8cd453f19..d541d436f01d 100644
--- a/drivers/power/avs/Makefile
+++ b/drivers/power/avs/Makefile
@@ -1,3 +1,2 @@
# SPDX-License-Identifier: GPL-2.0-only
obj-$(CONFIG_POWER_AVS_OMAP) += smartreflex.o
-obj-$(CONFIG_ROCKCHIP_IODOMAIN) += rockchip-io-domain.o
diff --git a/drivers/soc/rockchip/Kconfig b/drivers/soc/rockchip/Kconfig
index b71b73bf5fc5..2c13bf4dd5db 100644
--- a/drivers/soc/rockchip/Kconfig
+++ b/drivers/soc/rockchip/Kconfig
@@ -14,6 +14,14 @@ config ROCKCHIP_GRF
In a lot of cases there also need to be default settings initialized
to make some of them conform to expectations of the kernel.
+config ROCKCHIP_IODOMAIN
+ tristate "Rockchip IO domain support"
+ depends on OF
+ help
+ Say y here to enable support io domains on Rockchip SoCs. It is
+ necessary for the io domain setting of the SoC to match the
+ voltage supplied by the regulators.
+
config ROCKCHIP_PM_DOMAINS
bool "Rockchip generic power domain"
depends on PM
diff --git a/drivers/soc/rockchip/Makefile b/drivers/soc/rockchip/Makefile
index afca0a4c4b72..875032f7344e 100644
--- a/drivers/soc/rockchip/Makefile
+++ b/drivers/soc/rockchip/Makefile
@@ -3,4 +3,5 @@
# Rockchip Soc drivers
#
obj-$(CONFIG_ROCKCHIP_GRF) += grf.o
+obj-$(CONFIG_ROCKCHIP_IODOMAIN) += io-domain.o
obj-$(CONFIG_ROCKCHIP_PM_DOMAINS) += pm_domains.o
diff --git a/drivers/power/avs/rockchip-io-domain.c b/drivers/soc/rockchip/io-domain.c
similarity index 100%
rename from drivers/power/avs/rockchip-io-domain.c
rename to drivers/soc/rockchip/io-domain.c
--
2.25.1
All avs drivers have now been moved to their corresponding soc specific
directories. Additionally, they don't depend on the POWER_AVS Kconfig
anymore. Therefore, let's simply drop the drivers/power/avs directory
altogether.
Cc: Nishanth Menon <[email protected]>
Signed-off-by: Ulf Hansson <[email protected]>
---
drivers/power/Kconfig | 1 -
drivers/power/Makefile | 1 -
drivers/power/avs/Kconfig | 1 -
drivers/power/avs/Makefile | 1 -
4 files changed, 4 deletions(-)
delete mode 100644 drivers/power/avs/Kconfig
delete mode 100644 drivers/power/avs/Makefile
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index ff0350ca3b74..696bf77a7042 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -1,4 +1,3 @@
# SPDX-License-Identifier: GPL-2.0-only
-source "drivers/power/avs/Kconfig"
source "drivers/power/reset/Kconfig"
source "drivers/power/supply/Kconfig"
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index b7c2e372186b..effbf0377f32 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -1,4 +1,3 @@
# SPDX-License-Identifier: GPL-2.0-only
-obj-$(CONFIG_POWER_AVS) += avs/
obj-$(CONFIG_POWER_RESET) += reset/
obj-$(CONFIG_POWER_SUPPLY) += supply/
diff --git a/drivers/power/avs/Kconfig b/drivers/power/avs/Kconfig
deleted file mode 100644
index a4e40e534e6a..000000000000
--- a/drivers/power/avs/Kconfig
+++ /dev/null
@@ -1 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0-only
diff --git a/drivers/power/avs/Makefile b/drivers/power/avs/Makefile
deleted file mode 100644
index a4e40e534e6a..000000000000
--- a/drivers/power/avs/Makefile
+++ /dev/null
@@ -1 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0-only
--
2.25.1
On 18:05-20201006, Ulf Hansson wrote:
> All avs drivers have now been moved to their corresponding soc specific
> directories. Additionally, they don't depend on the POWER_AVS Kconfig
> anymore. Therefore, let's simply drop the drivers/power/avs directory
> altogether.
>
> Cc: Nishanth Menon <[email protected]>
> Signed-off-by: Ulf Hansson <[email protected]>
Reviewed-by: Nishanth Menon <[email protected]>
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
On 18:05-20201006, Ulf Hansson wrote:
> The avs drivers are all SoC specific drivers that doesn't share any code.
> Instead they are located in a directory, mostly to keep similar
> functionality together. From a maintenance point of view, it makes better
> sense to collect SoC specific drivers like these, into the SoC specific
> directories.
>
> Therefore, let's move the smartreflex driver for OMAP to the ti directory.
>
> Cc: Nishanth Menon <[email protected]>
> Cc: Aaro Koskinen <[email protected]>
> Cc: Tony Lindgren <[email protected]>
> Cc: [email protected]
> Signed-off-by: Ulf Hansson <[email protected]>
[...]
Reviewed-by: Nishanth Menon <[email protected]>
CCying Santosh to let him know as well.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Am Dienstag, 6. Oktober 2020, 18:05:14 CEST schrieb Ulf Hansson:
> The avs drivers are all SoC specific drivers that doesn't share any code.
> Instead they are located in a directory, mostly to keep similar
> functionality together. From a maintenance point of view, it makes better
> sense to collect SoC specific drivers like these, into the SoC specific
> directories.
>
> Therefore, let's move the rockchip-io driver to the rockchip directory.
>
> Cc: Heiko Stuebner <[email protected]>
> Cc: [email protected]
> Signed-off-by: Ulf Hansson <[email protected]>
Acked-by: Heiko Stuebner <[email protected]>
On Tue, Oct 6, 2020 at 6:05 PM Ulf Hansson <[email protected]> wrote:
>
> The avs drivers in drivers/power/avs/* are all SoC specific drivers that
> doesn't share any code. Instead they are located in a directory, mostly to keep
> similar functionality together. From a maintenance point of view, it makes
> better sense to collect SoC specific drivers like these, into the SoC specific
> directories.
>
> Therefore, this series moves the drivers, one by one - and in the end, it
> deletes the empty avs directory.
>
> It seems best to me, if this can be funneled via Rafael's linux-pm tree. Then
> when going forward, each driver should be managed through the SoC maintainer's
> trees.
That's fine by me.
I'd like to get an ACK from the arm-soc side on this, though.
Cheers!
+ Arnd
On Wed, 7 Oct 2020 at 17:09, Rafael J. Wysocki <[email protected]> wrote:
>
> On Tue, Oct 6, 2020 at 6:05 PM Ulf Hansson <[email protected]> wrote:
> >
> > The avs drivers in drivers/power/avs/* are all SoC specific drivers that
> > doesn't share any code. Instead they are located in a directory, mostly to keep
> > similar functionality together. From a maintenance point of view, it makes
> > better sense to collect SoC specific drivers like these, into the SoC specific
> > directories.
> >
> > Therefore, this series moves the drivers, one by one - and in the end, it
> > deletes the empty avs directory.
> >
> > It seems best to me, if this can be funneled via Rafael's linux-pm tree. Then
> > when going forward, each driver should be managed through the SoC maintainer's
> > trees.
>
> That's fine by me.
>
> I'd like to get an ACK from the arm-soc side on this, though.
I have looped in Arnd, to get his opinion on this.
Although, I think the people on cc already send pull requests to the
arm-soc maintainers (or perhaps it was these people you were referring
to), so just awaiting their acks should be fine, I guess.
Kind regards
Uffe
On Wed, Oct 7, 2020 at 5:23 PM Ulf Hansson <[email protected]> wrote:
>
> + Arnd
>
> On Wed, 7 Oct 2020 at 17:09, Rafael J. Wysocki <[email protected]> wrote:
> >
> > On Tue, Oct 6, 2020 at 6:05 PM Ulf Hansson <[email protected]> wrote:
> > >
> > > The avs drivers in drivers/power/avs/* are all SoC specific drivers that
> > > doesn't share any code. Instead they are located in a directory, mostly to keep
> > > similar functionality together. From a maintenance point of view, it makes
> > > better sense to collect SoC specific drivers like these, into the SoC specific
> > > directories.
> > >
> > > Therefore, this series moves the drivers, one by one - and in the end, it
> > > deletes the empty avs directory.
> > >
> > > It seems best to me, if this can be funneled via Rafael's linux-pm tree. Then
> > > when going forward, each driver should be managed through the SoC maintainer's
> > > trees.
> >
> > That's fine by me.
> >
> > I'd like to get an ACK from the arm-soc side on this, though.
>
> I have looped in Arnd, to get his opinion on this.
>
> Although, I think the people on cc already send pull requests to the
> arm-soc maintainers (or perhaps it was these people you were referring
> to), so just awaiting their acks should be fine, I guess.
OK
For now, I've taken patches [2-3/4] that have been ACKed.
When the [1/4] is ACKed, I'll take it too and apply the last one.
Thanks!
On Fri, 16 Oct 2020 at 18:30, Rafael J. Wysocki <[email protected]> wrote:
>
> On Wed, Oct 7, 2020 at 5:23 PM Ulf Hansson <[email protected]> wrote:
> >
> > + Arnd
> >
> > On Wed, 7 Oct 2020 at 17:09, Rafael J. Wysocki <[email protected]> wrote:
> > >
> > > On Tue, Oct 6, 2020 at 6:05 PM Ulf Hansson <[email protected]> wrote:
> > > >
> > > > The avs drivers in drivers/power/avs/* are all SoC specific drivers that
> > > > doesn't share any code. Instead they are located in a directory, mostly to keep
> > > > similar functionality together. From a maintenance point of view, it makes
> > > > better sense to collect SoC specific drivers like these, into the SoC specific
> > > > directories.
> > > >
> > > > Therefore, this series moves the drivers, one by one - and in the end, it
> > > > deletes the empty avs directory.
> > > >
> > > > It seems best to me, if this can be funneled via Rafael's linux-pm tree. Then
> > > > when going forward, each driver should be managed through the SoC maintainer's
> > > > trees.
> > >
> > > That's fine by me.
> > >
> > > I'd like to get an ACK from the arm-soc side on this, though.
> >
> > I have looped in Arnd, to get his opinion on this.
> >
> > Although, I think the people on cc already send pull requests to the
> > arm-soc maintainers (or perhaps it was these people you were referring
> > to), so just awaiting their acks should be fine, I guess.
>
> OK
>
> For now, I've taken patches [2-3/4] that have been ACKed.
>
> When the [1/4] is ACKed, I'll take it too and apply the last one.
Patch 1/4 has been acked now as well, so I think the remaining part of
this series is ready to go.
However, I noticed that Stephen Rothwell reported some merge conflicts
for arm-soc in linux-next. Quite trivial to resolve, though. Perhaps
an option to consider is to send this as material for v5.10-rc1 (or
maybe rc2) to avoid further conflicts during this release cycle? Just
an idea..
Kind regards
Uffe
On Wednesday, October 21, 2020 12:41:50 PM CEST Ulf Hansson wrote:
> On Fri, 16 Oct 2020 at 18:30, Rafael J. Wysocki <[email protected]> wrote:
> >
> > On Wed, Oct 7, 2020 at 5:23 PM Ulf Hansson <[email protected]> wrote:
> > >
> > > + Arnd
> > >
> > > On Wed, 7 Oct 2020 at 17:09, Rafael J. Wysocki <[email protected]> wrote:
> > > >
> > > > On Tue, Oct 6, 2020 at 6:05 PM Ulf Hansson <[email protected]> wrote:
> > > > >
> > > > > The avs drivers in drivers/power/avs/* are all SoC specific drivers that
> > > > > doesn't share any code. Instead they are located in a directory, mostly to keep
> > > > > similar functionality together. From a maintenance point of view, it makes
> > > > > better sense to collect SoC specific drivers like these, into the SoC specific
> > > > > directories.
> > > > >
> > > > > Therefore, this series moves the drivers, one by one - and in the end, it
> > > > > deletes the empty avs directory.
> > > > >
> > > > > It seems best to me, if this can be funneled via Rafael's linux-pm tree. Then
> > > > > when going forward, each driver should be managed through the SoC maintainer's
> > > > > trees.
> > > >
> > > > That's fine by me.
> > > >
> > > > I'd like to get an ACK from the arm-soc side on this, though.
> > >
> > > I have looped in Arnd, to get his opinion on this.
> > >
> > > Although, I think the people on cc already send pull requests to the
> > > arm-soc maintainers (or perhaps it was these people you were referring
> > > to), so just awaiting their acks should be fine, I guess.
> >
> > OK
> >
> > For now, I've taken patches [2-3/4] that have been ACKed.
> >
> > When the [1/4] is ACKed, I'll take it too and apply the last one.
>
> Patch 1/4 has been acked now as well, so I think the remaining part of
> this series is ready to go.
Agreed, I'm going to apply the remaining two patches from it tomorrow.
> However, I noticed that Stephen Rothwell reported some merge conflicts
> for arm-soc in linux-next. Quite trivial to resolve, though. Perhaps
> an option to consider is to send this as material for v5.10-rc1 (or
> maybe rc2) to avoid further conflicts during this release cycle? Just
> an idea..
Yes, I'm going to do that.
Thanks!