| Message ID | 1458303004-26445-1-git-send-email-xf@rock-chips.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Feng, Am Freitag, 18. März 2016, 20:10:04 schrieb Feng Xiao: > This driver will directly use cpufreq-dt driver as backend. > > As there is not a generic devicetree board file(rockchip.c) > on ARM64 architecture, so remove platform_device_register_simple > in rockchip.c and add a new cpufreq driver to support for all > Rockchip SoCs. > > Signed-off-by: Feng Xiao <xf@rock-chips.com> [...] > diff --git a/drivers/cpufreq/rockchip-cpufreq.c > b/drivers/cpufreq/rockchip-cpufreq.c new file mode 100644 > index 0000000..ecbadcd > --- /dev/null > +++ b/drivers/cpufreq/rockchip-cpufreq.c > @@ -0,0 +1,36 @@ > +/* > + * Rockchip Platforms CPUFreq Support > + * > + * Copyright (C) 2016 Fuzhou Rockchip Electronics Co., Ltd > + * > + * Feng Xiao <xf@rock-chips.com> > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License version 2 as > + * published by the Free Software Foundation. > + * > + * This program is distributed "as is" WITHOUT ANY WARRANTY of any > + * kind, whether express or implied; without even the implied warranty > + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + */ > + > +#include <linux/err.h> > +#include <linux/init.h> > +#include <linux/kernel.h> > +#include <linux/module.h> > +#include <linux/of.h> > +#include <linux/platform_device.h> > + > +static int __init rockchip_cpufreq_driver_init(void) > +{ > + struct platform_device *pdev; > + > + pdev = platform_device_register_simple("cpufreq-dt", -1, NULL, 0); > + return PTR_ERR_OR_ZERO(pdev); This would create that cpufreq-dt device on all non-Rockchip platforms compiled into the same kernel image as well - we definitly don't want that. Also, on both the rk3368 as well as the rk3399, you probably want the cluster- handling of arm-bL-cpufreq-dt. Contrary to its name it is _not_ limited to switching between clusters, but can also control frequencies of multiple cpu-clusters running at the same time. Implementation-wise, I guess doing it similar to the scpi-implementation might make more sense. Please take a look at drivers/clk/clk-scpi.c that registers the virtual cpufreq device there. So we could do something similar, move the cpufreq from mach-rockchip to the clock drivers and register the appropriate cpufreq-driver for each soc. cpufreq-dt for socs with a single cluster, the bL-thing for socs with multiple clusters. Heiko
On 18-03-16, 13:56, Heiko Stübner wrote: > Also, on both the rk3368 as well as the rk3399, you probably want the cluster- > handling of arm-bL-cpufreq-dt. > Contrary to its name it is _not_ limited to switching between clusters, but > can also control frequencies of multiple cpu-clusters running at the same > time. We aren't adding any new users to bL driver, please use cpufreq-dt as that also supports multiple clusters now.
Am Montag, 21. März 2016, 15:20:49 schrieb Viresh Kumar: > On 18-03-16, 13:56, Heiko Stübner wrote: > > Also, on both the rk3368 as well as the rk3399, you probably want the > > cluster- handling of arm-bL-cpufreq-dt. > > Contrary to its name it is _not_ limited to switching between clusters, > > but > > can also control frequencies of multiple cpu-clusters running at the same > > time. > > We aren't adding any new users to bL driver, please use cpufreq-dt as that > also supports multiple clusters now. I hadn't seen that yet ... nice that cpufreq-dt now also supports clusters :-) The other part still stands though, as we probably should register the platform-device somewhere else and not in some new special module. When everything is using cpufreq-dt now, I guess we could just add it to the core rockchip clk-code. Or was there some agreement where this should be done (obviously not the devicetree itself)?
On 21-03-16, 10:54, Heiko Stübner wrote: > I hadn't seen that yet ... nice that cpufreq-dt now also supports clusters :-) > > The other part still stands though, as we probably should register the > platform-device somewhere else and not in some new special module. > > When everything is using cpufreq-dt now, I guess we could just add it to the > core rockchip clk-code. Or was there some agreement where this should be done > (obviously not the devicetree itself)? Yeah, there was a discussion around creating a white or black list of platforms that want to create a platform device for cpufreq-dt. That can be done in cpufreq-dt.c or a new file, but I haven't worked out on that yet. You can do it from clk-code or from the driver that was added in this thread. Just that you need to match your platform's compatible string before doing that.
? 2016/3/21 17:58, Viresh Kumar ??: > On 21-03-16, 10:54, Heiko Stübner wrote: >> I hadn't seen that yet ... nice that cpufreq-dt now also supports clusters :-) >> >> The other part still stands though, as we probably should register the >> platform-device somewhere else and not in some new special module. >> >> When everything is using cpufreq-dt now, I guess we could just add it to the >> core rockchip clk-code. Or was there some agreement where this should be done >> (obviously not the devicetree itself)? Of_clk_init is called early, and platform_device_register_simple should be called after devices_init, it will be failed to do it from clk-code. So we need add a new file or add module_init to each clock controller driver(like clk-rk3368.c, clk-rk3399.c) ? > Yeah, there was a discussion around creating a white or black list of platforms > that want to create a platform device for cpufreq-dt. That can be done in > cpufreq-dt.c or a new file, but I haven't worked out on that yet. > > You can do it from clk-code or from the driver that was added in this thread. > Just that you need to match your platform's compatible string before doing that. Rockchip-cpufreq.c depends on ARM_ROCKCHIP_CPUFREQ, it will not be compiled on non-Rockchip platforms. The driver can support all Rockchip SoCs up to now, add of_machine_is_compatible may be redundant ? >
On 21-03-16, 21:24, Feng Xiao wrote: > Rockchip-cpufreq.c depends on ARM_ROCKCHIP_CPUFREQ, it will not be compiled > on non-Rockchip platforms. > The driver can support all Rockchip SoCs up to now, add > of_machine_is_compatible may be redundant ? Heard of Multi-platform kernels ?
Hi, Am Montag, 21. März 2016, 21:24:32 schrieb Feng Xiao: > ? 2016/3/21 17:58, Viresh Kumar ??: > > On 21-03-16, 10:54, Heiko Stübner wrote: > >> I hadn't seen that yet ... nice that cpufreq-dt now also supports > >> clusters :-) > >> > >> The other part still stands though, as we probably should register the > >> platform-device somewhere else and not in some new special module. > >> > >> When everything is using cpufreq-dt now, I guess we could just add it to > >> the core rockchip clk-code. Or was there some agreement where this > >> should be done (obviously not the devicetree itself)? > > Of_clk_init is called early, and platform_device_register_simple should > be called after devices_init, it will be failed to do it from clk-code. > So we need add a new file or add module_init to each clock controller > driver(like clk-rk3368.c, clk-rk3399.c) ? as Viresh said, it should be ok to do it like your approach creating a module in drivers/cpufreq. But the compatible check is necessary. Doing it this way also makes it easier to have > > Yeah, there was a discussion around creating a white or black list of > > platforms that want to create a platform device for cpufreq-dt. That can > > be done in cpufreq-dt.c or a new file, but I haven't worked out on that > > yet. > > > > You can do it from clk-code or from the driver that was added in this > > thread. Just that you need to match your platform's compatible string > > before doing that. > Rockchip-cpufreq.c depends on ARM_ROCKCHIP_CPUFREQ, it will not be > compiled on non-Rockchip platforms. > The driver can support all Rockchip SoCs up to now, add > of_machine_is_compatible may be redundant ? Please always keep multiplatform in mind. These days the kernel can be compiled for multiple architectures at the same time, so you can have support for Rockchip, Exynos, Qualcom and whatever in the same kernel image. Therefore a compile-time check is not enough and you need to check the actually running machine as well. Heiko
Am Montag, 21. März 2016, 16:13:40 schrieb Heiko Stübner: > Hi, > > Am Montag, 21. März 2016, 21:24:32 schrieb Feng Xiao: > > ? 2016/3/21 17:58, Viresh Kumar ??: > > > On 21-03-16, 10:54, Heiko Stübner wrote: > > >> I hadn't seen that yet ... nice that cpufreq-dt now also supports > > >> clusters :-) > > >> > > >> The other part still stands though, as we probably should register the > > >> platform-device somewhere else and not in some new special module. > > >> > > >> When everything is using cpufreq-dt now, I guess we could just add it > > >> to > > >> the core rockchip clk-code. Or was there some agreement where this > > >> should be done (obviously not the devicetree itself)? > > > > Of_clk_init is called early, and platform_device_register_simple should > > be called after devices_init, it will be failed to do it from clk-code. > > So we need add a new file or add module_init to each clock controller > > driver(like clk-rk3368.c, clk-rk3399.c) ? > > as Viresh said, it should be ok to do it like your approach creating a > module in drivers/cpufreq. But the compatible check is necessary. > > Doing it this way also makes it easier to have Seem like I forgot the complete my sentence here. This should've been Doing it this way also makes it easier to have everything go into cpufreq-dt once that whitelist appears that Viresh wrote about. So this might be better than to distribute this stuff around other subsystems, as I originally suggested. > > > > Yeah, there was a discussion around creating a white or black list of > > > platforms that want to create a platform device for cpufreq-dt. That can > > > be done in cpufreq-dt.c or a new file, but I haven't worked out on that > > > yet. > > > > > > You can do it from clk-code or from the driver that was added in this > > > thread. Just that you need to match your platform's compatible string > > > before doing that. > > > > Rockchip-cpufreq.c depends on ARM_ROCKCHIP_CPUFREQ, it will not be > > compiled on non-Rockchip platforms. > > The driver can support all Rockchip SoCs up to now, add > > of_machine_is_compatible may be redundant ? > > Please always keep multiplatform in mind. These days the kernel can be > compiled for multiple architectures at the same time, so you can have > support for Rockchip, Exynos, Qualcom and whatever in the same kernel > image. > > Therefore a compile-time check is not enough and you need to check the > actually running machine as well. > > > Heiko
I get it, thanks. ? 2016/3/21 23:52, Heiko Stübner ??: > Am Montag, 21. März 2016, 16:13:40 schrieb Heiko Stübner: >> Hi, >> >> Am Montag, 21. März 2016, 21:24:32 schrieb Feng Xiao: >>> ? 2016/3/21 17:58, Viresh Kumar ??: >>>> On 21-03-16, 10:54, Heiko Stübner wrote: >>>>> I hadn't seen that yet ... nice that cpufreq-dt now also supports >>>>> clusters :-) >>>>> >>>>> The other part still stands though, as we probably should register the >>>>> platform-device somewhere else and not in some new special module. >>>>> >>>>> When everything is using cpufreq-dt now, I guess we could just add it >>>>> to >>>>> the core rockchip clk-code. Or was there some agreement where this >>>>> should be done (obviously not the devicetree itself)? >>> Of_clk_init is called early, and platform_device_register_simple should >>> be called after devices_init, it will be failed to do it from clk-code. >>> So we need add a new file or add module_init to each clock controller >>> driver(like clk-rk3368.c, clk-rk3399.c) ? >> as Viresh said, it should be ok to do it like your approach creating a >> module in drivers/cpufreq. But the compatible check is necessary. >> >> Doing it this way also makes it easier to have > Seem like I forgot the complete my sentence here. This should've been > > Doing it this way also makes it easier to have everything go into cpufreq-dt > once that whitelist appears that Viresh wrote about. So this might be better > than to distribute this stuff around other subsystems, as I originally > suggested. > >>>> Yeah, there was a discussion around creating a white or black list of >>>> platforms that want to create a platform device for cpufreq-dt. That can >>>> be done in cpufreq-dt.c or a new file, but I haven't worked out on that >>>> yet. >>>> >>>> You can do it from clk-code or from the driver that was added in this >>>> thread. Just that you need to match your platform's compatible string >>>> before doing that. >>> Rockchip-cpufreq.c depends on ARM_ROCKCHIP_CPUFREQ, it will not be >>> compiled on non-Rockchip platforms. >>> The driver can support all Rockchip SoCs up to now, add >>> of_machine_is_compatible may be redundant ? >> Please always keep multiplatform in mind. These days the kernel can be >> compiled for multiple architectures at the same time, so you can have >> support for Rockchip, Exynos, Qualcom and whatever in the same kernel >> image. >> >> Therefore a compile-time check is not enough and you need to check the >> actually running machine as well. >> >> >> Heiko > > >
diff --git a/arch/arm/mach-rockchip/rockchip.c b/arch/arm/mach-rockchip/rockchip.c index 3f07cc5..beb71da 100644 --- a/arch/arm/mach-rockchip/rockchip.c +++ b/arch/arm/mach-rockchip/rockchip.c @@ -74,7 +74,6 @@ static void __init rockchip_dt_init(void) { rockchip_suspend_init(); of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL); - platform_device_register_simple("cpufreq-dt", 0, NULL, 0); } static const char * const rockchip_board_dt_compat[] = { diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm index 14b1f93..1786315 100644 --- a/drivers/cpufreq/Kconfig.arm +++ b/drivers/cpufreq/Kconfig.arm @@ -97,6 +97,16 @@ config ARM_OMAP2PLUS_CPUFREQ depends on ARCH_OMAP2PLUS default ARCH_OMAP2PLUS +config ARM_ROCKCHIP_CPUFREQ + tristate "Rockchip CPUfreq driver" + depends on ARCH_ROCKCHIP && CPUFREQ_DT + select PM_OPP + help + This adds the CPUFreq driver support for Rockchip SoCs. + The driver will directly use cpufreq-dt driver as backend. + + If in doubt, say N. + config ARM_S3C_CPUFREQ bool help diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile index 9e63fb1..91d8bb7 100644 --- a/drivers/cpufreq/Makefile +++ b/drivers/cpufreq/Makefile @@ -61,6 +61,7 @@ obj-$(CONFIG_ARM_MT8173_CPUFREQ) += mt8173-cpufreq.o obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ) += omap-cpufreq.o obj-$(CONFIG_ARM_PXA2xx_CPUFREQ) += pxa2xx-cpufreq.o obj-$(CONFIG_PXA3xx) += pxa3xx-cpufreq.o +obj-$(CONFIG_ARM_ROCKCHIP_CPUFREQ) += rockchip-cpufreq.o obj-$(CONFIG_ARM_S3C24XX_CPUFREQ) += s3c24xx-cpufreq.o obj-$(CONFIG_ARM_S3C24XX_CPUFREQ_DEBUGFS) += s3c24xx-cpufreq-debugfs.o obj-$(CONFIG_ARM_S3C2410_CPUFREQ) += s3c2410-cpufreq.o diff --git a/drivers/cpufreq/rockchip-cpufreq.c b/drivers/cpufreq/rockchip-cpufreq.c new file mode 100644 index 0000000..ecbadcd --- /dev/null +++ b/drivers/cpufreq/rockchip-cpufreq.c @@ -0,0 +1,36 @@ +/* + * Rockchip Platforms CPUFreq Support + * + * Copyright (C) 2016 Fuzhou Rockchip Electronics Co., Ltd + * + * Feng Xiao <xf@rock-chips.com> + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed "as is" WITHOUT ANY WARRANTY of any + * kind, whether express or implied; without even the implied warranty + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include <linux/err.h> +#include <linux/init.h> +#include <linux/kernel.h> +#include <linux/module.h> +#include <linux/of.h> +#include <linux/platform_device.h> + +static int __init rockchip_cpufreq_driver_init(void) +{ + struct platform_device *pdev; + + pdev = platform_device_register_simple("cpufreq-dt", -1, NULL, 0); + return PTR_ERR_OR_ZERO(pdev); +} +module_init(rockchip_cpufreq_driver_init); + +MODULE_AUTHOR("Feng Xiao <xf@rock-chips.com>"); +MODULE_DESCRIPTION("Rockchip cpufreq driver"); +MODULE_LICENSE("GPL v2");
This driver will directly use cpufreq-dt driver as backend. As there is not a generic devicetree board file(rockchip.c) on ARM64 architecture, so remove platform_device_register_simple in rockchip.c and add a new cpufreq driver to support for all Rockchip SoCs. Signed-off-by: Feng Xiao <xf@rock-chips.com> --- arch/arm/mach-rockchip/rockchip.c | 1 - drivers/cpufreq/Kconfig.arm | 10 ++++++++++ drivers/cpufreq/Makefile | 1 + drivers/cpufreq/rockchip-cpufreq.c | 36 ++++++++++++++++++++++++++++++++++++ 4 files changed, 47 insertions(+), 1 deletion(-) create mode 100644 drivers/cpufreq/rockchip-cpufreq.c