| Message ID | 20201006160516.319830-1-ulf.hansson@linaro.org |
|---|---|
| Headers | show |
| Series | power: avs: Move drivers to the soc directories and drop avs | expand |
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>
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!
+ 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
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!
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 >
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
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!
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%)