Hi Nicolas, Am 06.06.19 um 16:22 schrieb Nicolas Saenz Julienne: > Raspberry Pi's firmware offers and interface though which update it's > performance requirements. It allows us to request for specific runtime > frequencies, which the firmware might or might not respect, depending on > the firmware configuration and thermals. > > As the maximum and minimum frequencies are configurable in the firmware > there is no way to know in advance their values. So the Raspberry Pi > cpufreq driver queries them, builds an opp frequency table to then > launch cpufreq-dt. > > Also, as the firmware interface might be configured as a module, making > the cpu clock unavailable during init, this implements a full fledged > driver, as opposed to most drivers registering cpufreq-dt, which only > make use of an init routine. > > Signed-off-by: Nicolas Saenz Julienne <[email protected]> > Acked-by: Eric Anholt <[email protected]> > > --- > > Changes since v1: > - Remove compatible checks > - Add module support, now full fledged driver > - Use NULL in clk_get() > > drivers/cpufreq/Kconfig.arm | 8 +++ > drivers/cpufreq/Makefile | 1 + > drivers/cpufreq/raspberrypi-cpufreq.c | 100 ++++++++++++++++++++++++++ > 3 files changed, 109 insertions(+) > create mode 100644 drivers/cpufreq/raspberrypi-cpufreq.c > > diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm > index f8129edc145e..5e9204d443ff 100644 > --- a/drivers/cpufreq/Kconfig.arm > +++ b/drivers/cpufreq/Kconfig.arm > @@ -133,6 +133,14 @@ config ARM_QCOM_CPUFREQ_HW > The driver implements the cpufreq interface for this HW engine. > Say Y if you want to support CPUFreq HW. > > +config ARM_RASPBERRYPI_CPUFREQ > + tristate "Raspberry Pi cpufreq support" > + depends on CLK_RASPBERRYPI || COMPILE_TEST > + help > + This adds the CPUFreq driver for Raspberry Pi > + > + If in doubt, say N. > + > config ARM_S3C_CPUFREQ > bool > help > diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile > index 689b26c6f949..121c1acb66c0 100644 > --- a/drivers/cpufreq/Makefile > +++ b/drivers/cpufreq/Makefile > @@ -64,6 +64,7 @@ obj-$(CONFIG_ARM_PXA2xx_CPUFREQ) += pxa2xx-cpufreq.o > obj-$(CONFIG_PXA3xx) += pxa3xx-cpufreq.o > obj-$(CONFIG_ARM_QCOM_CPUFREQ_HW) += qcom-cpufreq-hw.o > obj-$(CONFIG_ARM_QCOM_CPUFREQ_KRYO) += qcom-cpufreq-kryo.o > +obj-$(CONFIG_ARM_RASPBERRYPI_CPUFREQ) += raspberrypi-cpufreq.o > obj-$(CONFIG_ARM_S3C2410_CPUFREQ) += s3c2410-cpufreq.o > obj-$(CONFIG_ARM_S3C2412_CPUFREQ) += s3c2412-cpufreq.o > obj-$(CONFIG_ARM_S3C2416_CPUFREQ) += s3c2416-cpufreq.o > diff --git a/drivers/cpufreq/raspberrypi-cpufreq.c > b/drivers/cpufreq/raspberrypi-cpufreq.c > new file mode 100644 > index 000000000000..99b59d5a50aa > --- /dev/null > +++ b/drivers/cpufreq/raspberrypi-cpufreq.c > @@ -0,0 +1,100 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Raspberry Pi cpufreq driver > + * > + * Copyright (C) 2019, Nicolas Saenz Julienne <[email protected]> > + */ > + > +#include <linux/clk.h> > +#include <linux/cpu.h> > +#include <linux/cpufreq.h> > +#include <linux/module.h> > +#include <linux/platform_device.h> > +#include <linux/pm_opp.h> > + > +static struct platform_device *cpufreq_dt; > + > +static int raspberrypi_cpufreq_probe(struct platform_device *pdev) > +{ > + struct device *cpu_dev; > + unsigned long min, max; > + unsigned long rate; > + struct clk *clk; > + int ret; > + > + cpu_dev = get_cpu_device(0); > + if (!cpu_dev) { > + pr_err("Cannot get CPU for cpufreq driver\n"); > + return -ENODEV; > + } > + > + clk = clk_get(cpu_dev, NULL); > + if (IS_ERR(clk)) { > + dev_err(cpu_dev, "Cannot get clock for CPU0\n"); > + return PTR_ERR(clk); > + } > + > + /* > + * The max and min frequencies are configurable in the Raspberry Pi > + * firmware, so we query them at runtime > + */ > + min = clk_round_rate(clk, 0); > + max = clk_round_rate(clk, ULONG_MAX); > + clk_put(clk); > + > + for (rate = min; rate < max; rate += 100000000) { > + ret = dev_pm_opp_add(cpu_dev, rate, 0); > + if (ret) > + goto remove_opp; > + }
i played a little bit with my Raspberry Pi Zero W and this series. Looks fine so far. Sorry for this nitpicking, but i expect user questions about the differences between sysfs and vcgencmd measure_clock. scaling_available_frequencies gives 699999 799999 899999 999999 but vcgencmd measure_clock return the rounded up values. I know we shouldn't fake anything, but adding the OPPs rounded up may avoid confusion. Stefan
