mbox series

[0/4] power: avs: Move drivers to the soc directories and drop avs

Message ID 20201006160516.319830-1-ulf.hansson@linaro.org
Headers show
Series power: avs: Move drivers to the soc directories and drop avs | expand

Message

Ulf Hansson Oct. 6, 2020, 4:05 p.m. UTC
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%)

Comments

Heiko Stuebner Oct. 7, 2020, 8:39 a.m. UTC | #1
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 <heiko@sntech.de>
> Cc: linux-rockchip@lists.infradead.org
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

Acked-by: Heiko Stuebner <heiko@sntech.de>
Rafael J. Wysocki Oct. 7, 2020, 3:09 p.m. UTC | #2
On Tue, Oct 6, 2020 at 6:05 PM Ulf Hansson <ulf.hansson@linaro.org> 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!
Ulf Hansson Oct. 7, 2020, 3:23 p.m. UTC | #3
+ Arnd

On Wed, 7 Oct 2020 at 17:09, Rafael J. Wysocki <rafael@kernel.org> wrote:
>

> On Tue, Oct 6, 2020 at 6:05 PM Ulf Hansson <ulf.hansson@linaro.org> 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
Rafael J. Wysocki Oct. 16, 2020, 4:30 p.m. UTC | #4
On Wed, Oct 7, 2020 at 5:23 PM Ulf Hansson <ulf.hansson@linaro.org> wrote:
>

> + Arnd

>

> On Wed, 7 Oct 2020 at 17:09, Rafael J. Wysocki <rafael@kernel.org> wrote:

> >

> > On Tue, Oct 6, 2020 at 6:05 PM Ulf Hansson <ulf.hansson@linaro.org> 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!
Bjorn Andersson Oct. 16, 2020, 6:11 p.m. UTC | #5
On Tue 06 Oct 11:05 CDT 2020, 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 qcom-cpr driver to the qcom directory.
> 
> Cc: Niklas Cassel <nks@flawful.org>
> Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
> Cc: Andy Gross <agross@kernel.org>
> Cc: linux-arm-msm@vger.kernel.org
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>

Regards,
Bjorn

> ---
>  MAINTAINERS                                      |  2 +-
>  drivers/power/avs/Kconfig                        | 16 ----------------
>  drivers/power/avs/Makefile                       |  1 -
>  drivers/soc/qcom/Kconfig                         | 16 ++++++++++++++++
>  drivers/soc/qcom/Makefile                        |  1 +
>  drivers/{power/avs/qcom-cpr.c => soc/qcom/cpr.c} |  0
>  6 files changed, 18 insertions(+), 18 deletions(-)
>  rename drivers/{power/avs/qcom-cpr.c => soc/qcom/cpr.c} (100%)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 4f1a56f6efaa..f51dd1944fe6 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -14337,7 +14337,7 @@ L:	linux-pm@vger.kernel.org
>  L:	linux-arm-msm@vger.kernel.org
>  S:	Maintained
>  F:	Documentation/devicetree/bindings/power/avs/qcom,cpr.txt
> -F:	drivers/power/avs/qcom-cpr.c
> +F:	drivers/soc/qcom/cpr.c
>  
>  QUALCOMM CPUFREQ DRIVER MSM8996/APQ8096
>  M:	Ilia Lin <ilia.lin@kernel.org>
> diff --git a/drivers/power/avs/Kconfig b/drivers/power/avs/Kconfig
> index cdb4237bfd02..089b6244b716 100644
> --- a/drivers/power/avs/Kconfig
> +++ b/drivers/power/avs/Kconfig
> @@ -12,22 +12,6 @@ menuconfig POWER_AVS
>  
>  	  Say Y here to enable Adaptive Voltage Scaling class support.
>  
> -config QCOM_CPR
> -	tristate "QCOM Core Power Reduction (CPR) support"
> -	depends on POWER_AVS && HAS_IOMEM
> -	select PM_OPP
> -	select REGMAP
> -	help
> -	  Say Y here to enable support for the CPR hardware found on Qualcomm
> -	  SoCs like QCS404.
> -
> -	  This driver populates CPU OPPs tables and makes adjustments to the
> -	  tables based on feedback from the CPR hardware. If you want to do
> -	  CPUfrequency scaling say Y here.
> -
> -	  To compile this driver as a module, choose M here: the module will
> -	  be called qcom-cpr
> -
>  config ROCKCHIP_IODOMAIN
>  	tristate "Rockchip IO domain support"
>  	depends on POWER_AVS && ARCH_ROCKCHIP && OF
> diff --git a/drivers/power/avs/Makefile b/drivers/power/avs/Makefile
> index 9007d05853e2..a1b8cd453f19 100644
> --- a/drivers/power/avs/Makefile
> +++ b/drivers/power/avs/Makefile
> @@ -1,4 +1,3 @@
>  # SPDX-License-Identifier: GPL-2.0-only
>  obj-$(CONFIG_POWER_AVS_OMAP)		+= smartreflex.o
> -obj-$(CONFIG_QCOM_CPR)			+= qcom-cpr.o
>  obj-$(CONFIG_ROCKCHIP_IODOMAIN)		+= rockchip-io-domain.o
> diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
> index 3dc3e3d61ea3..6a3b69b43ad5 100644
> --- a/drivers/soc/qcom/Kconfig
> +++ b/drivers/soc/qcom/Kconfig
> @@ -26,6 +26,22 @@ config QCOM_COMMAND_DB
>  	  resource on a RPM-hardened platform must use this database to get
>  	  SoC specific identifier and information for the shared resources.
>  
> +config QCOM_CPR
> +	tristate "QCOM Core Power Reduction (CPR) support"
> +	depends on ARCH_QCOM && HAS_IOMEM
> +	select PM_OPP
> +	select REGMAP
> +	help
> +	  Say Y here to enable support for the CPR hardware found on Qualcomm
> +	  SoCs like QCS404.
> +
> +	  This driver populates CPU OPPs tables and makes adjustments to the
> +	  tables based on feedback from the CPR hardware. If you want to do
> +	  CPUfrequency scaling say Y here.
> +
> +	  To compile this driver as a module, choose M here: the module will
> +	  be called qcom-cpr
> +
>  config QCOM_GENI_SE
>  	tristate "QCOM GENI Serial Engine Driver"
>  	depends on ARCH_QCOM || COMPILE_TEST
> diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
> index 93392d9dc7f7..ad675a6593d0 100644
> --- a/drivers/soc/qcom/Makefile
> +++ b/drivers/soc/qcom/Makefile
> @@ -3,6 +3,7 @@ CFLAGS_rpmh-rsc.o := -I$(src)
>  obj-$(CONFIG_QCOM_AOSS_QMP) +=	qcom_aoss.o
>  obj-$(CONFIG_QCOM_GENI_SE) +=	qcom-geni-se.o
>  obj-$(CONFIG_QCOM_COMMAND_DB) += cmd-db.o
> +obj-$(CONFIG_QCOM_CPR)		+= cpr.o
>  obj-$(CONFIG_QCOM_GSBI)	+=	qcom_gsbi.o
>  obj-$(CONFIG_QCOM_MDT_LOADER)	+= mdt_loader.o
>  obj-$(CONFIG_QCOM_OCMEM)	+= ocmem.o
> diff --git a/drivers/power/avs/qcom-cpr.c b/drivers/soc/qcom/cpr.c
> similarity index 100%
> rename from drivers/power/avs/qcom-cpr.c
> rename to drivers/soc/qcom/cpr.c
> -- 
> 2.25.1
>
Ulf Hansson Oct. 21, 2020, 10:41 a.m. UTC | #6
On Fri, 16 Oct 2020 at 18:30, Rafael J. Wysocki <rafael@kernel.org> wrote:
>
> On Wed, Oct 7, 2020 at 5:23 PM Ulf Hansson <ulf.hansson@linaro.org> wrote:
> >
> > + Arnd
> >
> > On Wed, 7 Oct 2020 at 17:09, Rafael J. Wysocki <rafael@kernel.org> wrote:
> > >
> > > On Tue, Oct 6, 2020 at 6:05 PM Ulf Hansson <ulf.hansson@linaro.org> 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
Rafael J. Wysocki Oct. 21, 2020, 6:19 p.m. UTC | #7
On Wednesday, October 21, 2020 12:41:50 PM CEST Ulf Hansson wrote:
> On Fri, 16 Oct 2020 at 18:30, Rafael J. Wysocki <rafael@kernel.org> wrote:
> >
> > On Wed, Oct 7, 2020 at 5:23 PM Ulf Hansson <ulf.hansson@linaro.org> wrote:
> > >
> > > + Arnd
> > >
> > > On Wed, 7 Oct 2020 at 17:09, Rafael J. Wysocki <rafael@kernel.org> wrote:
> > > >
> > > > On Tue, Oct 6, 2020 at 6:05 PM Ulf Hansson <ulf.hansson@linaro.org> 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!