* [PATCH v12 0/2] Kryo CPU scaling driver @ 2018-05-24 8:57 Ilia Lin 2018-05-24 8:57 ` [PATCH v12 1/2] cpufreq: Add " Ilia Lin ` (3 more replies) 0 siblings, 4 replies; 12+ messages in thread From: Ilia Lin @ 2018-05-24 8:57 UTC (permalink / raw) To: vireshk, nm, sboyd, robh, mark.rutland, rjw Cc: linux-pm, devicetree, linux-kernel, ilialin [v12] * Addressed comments from Sudeep and Viresh about the single init [v11] * Addressed comment from Russel about device_node reference * Addressed comment from Sudeep about the late_initcall * Transformed init into probe to take care of deferals [v10] * Split the series into domains * Addressed comments from Viresh and Sudeep about logical CPU numbering. The qcom-cpufreq-kryo driver is aimed to support different SOC versions. The driver reads eFuse information and chooses the required OPP subset by passing the OPP supported-hw parameter. The series depends on the series from Viresh: https://patchwork.kernel.org/patch/10418139/ The previous spin was here: https://patchwork.kernel.org/patch/10421143/ Ilia Lin (2): cpufreq: Add Kryo CPU scaling driver dt-bindings: cpufreq: Document operating-points-v2-kryo-cpu .../devicetree/bindings/opp/kryo-cpufreq.txt | 680 +++++++++++++++++++++ drivers/cpufreq/Kconfig.arm | 10 + drivers/cpufreq/Makefile | 1 + drivers/cpufreq/cpufreq-dt-platdev.c | 3 + drivers/cpufreq/qcom-cpufreq-kryo.c | 194 ++++++ 5 files changed, 888 insertions(+) create mode 100644 Documentation/devicetree/bindings/opp/kryo-cpufreq.txt create mode 100644 drivers/cpufreq/qcom-cpufreq-kryo.c -- 1.9.1 ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH v12 1/2] cpufreq: Add Kryo CPU scaling driver 2018-05-24 8:57 [PATCH v12 0/2] Kryo CPU scaling driver Ilia Lin @ 2018-05-24 8:57 ` Ilia Lin 2018-05-24 12:51 ` Sudeep Holla 2018-05-24 8:57 ` [PATCH v12 2/2] dt-bindings: cpufreq: Document operating-points-v2-kryo-cpu Ilia Lin ` (2 subsequent siblings) 3 siblings, 1 reply; 12+ messages in thread From: Ilia Lin @ 2018-05-24 8:57 UTC (permalink / raw) To: vireshk, nm, sboyd, robh, mark.rutland, rjw Cc: linux-pm, devicetree, linux-kernel, ilialin In Certain QCOM SoCs like apq8096 and msm8996 that have KRYO processors, the CPU frequency subset and voltage value of each OPP varies based on the silicon variant in use. Qualcomm Process Voltage Scaling Tables defines the voltage and frequency value based on the msm-id in SMEM and speedbin blown in the efuse combination. The qcom-cpufreq-kryo driver reads the msm-id and efuse value from the SoC to provide the OPP framework with required information. This is used to determine the voltage and frequency value for each OPP of operating-points-v2 table when it is parsed by the OPP framework. Signed-off-by: Ilia Lin <ilialin@codeaurora.org> --- drivers/cpufreq/Kconfig.arm | 10 ++ drivers/cpufreq/Makefile | 1 + drivers/cpufreq/cpufreq-dt-platdev.c | 3 + drivers/cpufreq/qcom-cpufreq-kryo.c | 194 +++++++++++++++++++++++++++++++++++ 4 files changed, 208 insertions(+) create mode 100644 drivers/cpufreq/qcom-cpufreq-kryo.c diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm index de55c7d..0bfd40e 100644 --- a/drivers/cpufreq/Kconfig.arm +++ b/drivers/cpufreq/Kconfig.arm @@ -124,6 +124,16 @@ config ARM_OMAP2PLUS_CPUFREQ depends on ARCH_OMAP2PLUS default ARCH_OMAP2PLUS +config ARM_QCOM_CPUFREQ_KRYO + bool "Qualcomm Kryo based CPUFreq" + depends on QCOM_QFPROM + depends on QCOM_SMEM + select PM_OPP + help + This adds the CPUFreq driver for Qualcomm Kryo SoC based boards. + + If in doubt, say N. + config ARM_S3C_CPUFREQ bool help diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile index 8d24ade..fb4a2ec 100644 --- a/drivers/cpufreq/Makefile +++ b/drivers/cpufreq/Makefile @@ -65,6 +65,7 @@ obj-$(CONFIG_MACH_MVEBU_V7) += mvebu-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_QCOM_CPUFREQ_KRYO) += qcom-cpufreq-kryo.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/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c index 3b585e4..77d6ab8 100644 --- a/drivers/cpufreq/cpufreq-dt-platdev.c +++ b/drivers/cpufreq/cpufreq-dt-platdev.c @@ -118,6 +118,9 @@ { .compatible = "nvidia,tegra124", }, + { .compatible = "qcom,apq8096", }, + { .compatible = "qcom,msm8996", }, + { .compatible = "st,stih407", }, { .compatible = "st,stih410", }, diff --git a/drivers/cpufreq/qcom-cpufreq-kryo.c b/drivers/cpufreq/qcom-cpufreq-kryo.c new file mode 100644 index 0000000..9fe379c --- /dev/null +++ b/drivers/cpufreq/qcom-cpufreq-kryo.c @@ -0,0 +1,194 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (c) 2018, The Linux Foundation. All rights reserved. + */ + +/* + * In Certain QCOM SoCs like apq8096 and msm8996 that have KRYO processors, + * the CPU frequency subset and voltage value of each OPP varies + * based on the silicon variant in use. Qualcomm Process Voltage Scaling Tables + * defines the voltage and frequency value based on the msm-id in SMEM + * and speedbin blown in the efuse combination. + * The qcom-cpufreq-kryo driver reads the msm-id and efuse value from the SoC + * to provide the OPP framework with required information. + * This is used to determine the voltage and frequency value for each OPP of + * operating-points-v2 table when it is parsed by the OPP framework. + */ + +#include <linux/cpu.h> +#include <linux/err.h> +#include <linux/init.h> +#include <linux/kernel.h> +#include <linux/module.h> +#include <linux/nvmem-consumer.h> +#include <linux/of.h> +#include <linux/platform_device.h> +#include <linux/pm_opp.h> +#include <linux/slab.h> +#include <linux/soc/qcom/smem.h> + +#define MSM_ID_SMEM 137 + +enum _msm_id { + MSM8996V3 = 0xF6ul, + APQ8096V3 = 0x123ul, + MSM8996SG = 0x131ul, + APQ8096SG = 0x138ul, +}; + +enum _msm8996_version { + MSM8996_V3, + MSM8996_SG, + NUM_OF_MSM8996_VERSIONS, +}; + +static enum _msm8996_version __init qcom_cpufreq_kryo_get_msm_id(void) +{ + size_t len; + u32 *msm_id; + enum _msm8996_version version; + + msm_id = qcom_smem_get(QCOM_SMEM_HOST_ANY, MSM_ID_SMEM, &len); + /* The first 4 bytes are format, next to them is the actual msm-id */ + msm_id++; + + switch ((enum _msm_id)*msm_id) { + case MSM8996V3: + case APQ8096V3: + version = MSM8996_V3; + break; + case MSM8996SG: + case APQ8096SG: + version = MSM8996_SG; + break; + default: + version = NUM_OF_MSM8996_VERSIONS; + } + + return version; +} + +static int qcom_cpufreq_kryo_probe(struct platform_device *pdev) +{ + struct opp_table *opp_tables[NR_CPUS] = {0}; + struct platform_device *cpufreq_dt_pdev; + enum _msm8996_version msm8996_version; + struct nvmem_cell *speedbin_nvmem; + struct device_node *np; + struct device *cpu_dev; + unsigned cpu; + u8 *speedbin; + u32 versions; + size_t len; + int ret; + + cpu_dev = get_cpu_device(0); + if (NULL == cpu_dev) + return -ENODEV; + + msm8996_version = qcom_cpufreq_kryo_get_msm_id(); + if (NUM_OF_MSM8996_VERSIONS == msm8996_version) { + dev_err(cpu_dev, "Not Snapdragon 820/821!"); + return -ENODEV; + } + + np = dev_pm_opp_of_get_opp_desc_node(cpu_dev); + if (IS_ERR(np)) + return PTR_ERR(np); + + if (!of_device_is_compatible(np, "operating-points-v2-kryo-cpu")) { + of_node_put(np); + return -ENOENT; + } + + speedbin_nvmem = of_nvmem_cell_get(np, NULL); + of_node_put(np); + if (IS_ERR(speedbin_nvmem)) { + dev_err(cpu_dev, "Could not get nvmem cell: %ld\n", + PTR_ERR(speedbin_nvmem)); + return PTR_ERR(speedbin_nvmem); + } + + speedbin = nvmem_cell_read(speedbin_nvmem, &len); + nvmem_cell_put(speedbin_nvmem); + + switch (msm8996_version) { + case MSM8996_V3: + versions = 1 << (unsigned int)(*speedbin); + break; + case MSM8996_SG: + versions = 1 << ((unsigned int)(*speedbin) + 4); + break; + default: + BUG(); + break; + } + + for_each_possible_cpu(cpu) { + cpu_dev = get_cpu_device(cpu); + if (NULL == cpu_dev) { + ret = -ENODEV; + goto free_opp; + } + + opp_tables[cpu] = dev_pm_opp_set_supported_hw(cpu_dev, + &versions, 1); + if (IS_ERR(opp_tables[cpu])) { + ret = PTR_ERR(opp_tables[cpu]); + dev_err(cpu_dev, "Failed to set supported hardware\n"); + goto free_opp; + } + } + + cpufreq_dt_pdev = platform_device_register_simple("cpufreq-dt", -1, + NULL, 0); + if (!IS_ERR(cpufreq_dt_pdev)) + return 0; + + ret = PTR_ERR(cpufreq_dt_pdev); + dev_err(cpu_dev, "Failed to register platform device\n"); + +free_opp: + for_each_possible_cpu(cpu) { + if (IS_ERR_OR_NULL(opp_tables[cpu])) + break; + dev_pm_opp_put_supported_hw(opp_tables[cpu]); + } + + return ret; +} + +static struct platform_driver qcom_cpufreq_kryo_driver = { + .probe = qcom_cpufreq_kryo_probe, + .driver = { + .name = "qcom-cpufreq-kryo", + }, +}; + +/* + * Since the driver depends on smem and nvmem drivers, which may + * return EPROBE_DEFER, all the real activity is done in the probe, + * which may be defered as well. The init here is only registering + * the driver and the platform device. + */ +static int __init qcom_cpufreq_kryo_init(void) +{ + int ret; + + ret = platform_driver_register(&qcom_cpufreq_kryo_driver); + if (unlikely(ret < 0)) + return ret; + + ret = PTR_ERR_OR_ZERO(platform_device_register_simple( + "qcom-cpufreq-kryo", -1, NULL, 0)); + if (unlikely(ret < 0)) { + platform_driver_unregister(&qcom_cpufreq_kryo_driver); + return ret; + } + + return 0; +} +module_init(qcom_cpufreq_kryo_init); + +MODULE_DESCRIPTION("Qualcomm Technologies, Inc. Kryo CPUfreq driver"); +MODULE_LICENSE("GPL v2"); -- 1.9.1 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH v12 1/2] cpufreq: Add Kryo CPU scaling driver 2018-05-24 8:57 ` [PATCH v12 1/2] cpufreq: Add " Ilia Lin @ 2018-05-24 12:51 ` Sudeep Holla 2018-05-24 13:03 ` ilialin 0 siblings, 1 reply; 12+ messages in thread From: Sudeep Holla @ 2018-05-24 12:51 UTC (permalink / raw) To: Ilia Lin, vireshk, nm, sboyd, robh, mark.rutland, rjw Cc: Sudeep Holla, linux-pm, devicetree, linux-kernel Hi Ilia, On 24/05/18 09:57, Ilia Lin wrote: > In Certain QCOM SoCs like apq8096 and msm8996 that have KRYO processors, > the CPU frequency subset and voltage value of each OPP varies > based on the silicon variant in use. Qualcomm Process Voltage Scaling Tables > defines the voltage and frequency value based on the msm-id in SMEM > and speedbin blown in the efuse combination. > The qcom-cpufreq-kryo driver reads the msm-id and efuse value from the SoC > to provide the OPP framework with required information. > This is used to determine the voltage and frequency value for each OPP of > operating-points-v2 table when it is parsed by the OPP framework. > > Signed-off-by: Ilia Lin <ilialin@codeaurora.org> > --- > drivers/cpufreq/Kconfig.arm | 10 ++ > drivers/cpufreq/Makefile | 1 + > drivers/cpufreq/cpufreq-dt-platdev.c | 3 + > drivers/cpufreq/qcom-cpufreq-kryo.c | 194 +++++++++++++++++++++++++++++++++++ > 4 files changed, 208 insertions(+) > create mode 100644 drivers/cpufreq/qcom-cpufreq-kryo.c > > diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm > index de55c7d..0bfd40e 100644 > --- a/drivers/cpufreq/Kconfig.arm > +++ b/drivers/cpufreq/Kconfig.arm > @@ -124,6 +124,16 @@ config ARM_OMAP2PLUS_CPUFREQ > depends on ARCH_OMAP2PLUS > default ARCH_OMAP2PLUS > > +config ARM_QCOM_CPUFREQ_KRYO > + bool "Qualcomm Kryo based CPUFreq" > + depends on QCOM_QFPROM > + depends on QCOM_SMEM > + select PM_OPP > + help > + This adds the CPUFreq driver for Qualcomm Kryo SoC based boards. > + > + If in doubt, say N. > + > config ARM_S3C_CPUFREQ > bool > help > diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile > index 8d24ade..fb4a2ec 100644 > --- a/drivers/cpufreq/Makefile > +++ b/drivers/cpufreq/Makefile > @@ -65,6 +65,7 @@ obj-$(CONFIG_MACH_MVEBU_V7) += mvebu-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_QCOM_CPUFREQ_KRYO) += qcom-cpufreq-kryo.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/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c > index 3b585e4..77d6ab8 100644 > --- a/drivers/cpufreq/cpufreq-dt-platdev.c > +++ b/drivers/cpufreq/cpufreq-dt-platdev.c > @@ -118,6 +118,9 @@ > > { .compatible = "nvidia,tegra124", }, > > + { .compatible = "qcom,apq8096", }, > + { .compatible = "qcom,msm8996", }, > + > { .compatible = "st,stih407", }, > { .compatible = "st,stih410", }, > > diff --git a/drivers/cpufreq/qcom-cpufreq-kryo.c b/drivers/cpufreq/qcom-cpufreq-kryo.c > new file mode 100644 > index 0000000..9fe379c > --- /dev/null > +++ b/drivers/cpufreq/qcom-cpufreq-kryo.c > @@ -0,0 +1,194 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright (c) 2018, The Linux Foundation. All rights reserved. > + */ > + > +/* > + * In Certain QCOM SoCs like apq8096 and msm8996 that have KRYO processors, > + * the CPU frequency subset and voltage value of each OPP varies > + * based on the silicon variant in use. Qualcomm Process Voltage Scaling Tables > + * defines the voltage and frequency value based on the msm-id in SMEM > + * and speedbin blown in the efuse combination. > + * The qcom-cpufreq-kryo driver reads the msm-id and efuse value from the SoC > + * to provide the OPP framework with required information. > + * This is used to determine the voltage and frequency value for each OPP of > + * operating-points-v2 table when it is parsed by the OPP framework. > + */ > + > +#include <linux/cpu.h> > +#include <linux/err.h> > +#include <linux/init.h> > +#include <linux/kernel.h> > +#include <linux/module.h> > +#include <linux/nvmem-consumer.h> > +#include <linux/of.h> > +#include <linux/platform_device.h> > +#include <linux/pm_opp.h> > +#include <linux/slab.h> > +#include <linux/soc/qcom/smem.h> > + > +#define MSM_ID_SMEM 137 > + > +enum _msm_id { > + MSM8996V3 = 0xF6ul, > + APQ8096V3 = 0x123ul, > + MSM8996SG = 0x131ul, > + APQ8096SG = 0x138ul, > +}; > + > +enum _msm8996_version { > + MSM8996_V3, > + MSM8996_SG, > + NUM_OF_MSM8996_VERSIONS, > +}; > + > +static enum _msm8996_version __init qcom_cpufreq_kryo_get_msm_id(void) > +{ > + size_t len; > + u32 *msm_id; > + enum _msm8996_version version; > + > + msm_id = qcom_smem_get(QCOM_SMEM_HOST_ANY, MSM_ID_SMEM, &len); > + /* The first 4 bytes are format, next to them is the actual msm-id */ > + msm_id++; > + > + switch ((enum _msm_id)*msm_id) { > + case MSM8996V3: > + case APQ8096V3: > + version = MSM8996_V3; > + break; > + case MSM8996SG: > + case APQ8096SG: > + version = MSM8996_SG; > + break; > + default: > + version = NUM_OF_MSM8996_VERSIONS; > + } > + > + return version; > +} > + > +static int qcom_cpufreq_kryo_probe(struct platform_device *pdev) > +{ > + struct opp_table *opp_tables[NR_CPUS] = {0}; > + struct platform_device *cpufreq_dt_pdev; > + enum _msm8996_version msm8996_version; > + struct nvmem_cell *speedbin_nvmem; > + struct device_node *np; > + struct device *cpu_dev; > + unsigned cpu; > + u8 *speedbin; > + u32 versions; > + size_t len; > + int ret; > + > + cpu_dev = get_cpu_device(0); > + if (NULL == cpu_dev) > + return -ENODEV; > + > + msm8996_version = qcom_cpufreq_kryo_get_msm_id(); > + if (NUM_OF_MSM8996_VERSIONS == msm8996_version) { > + dev_err(cpu_dev, "Not Snapdragon 820/821!"); > + return -ENODEV; > + } > + > + np = dev_pm_opp_of_get_opp_desc_node(cpu_dev); > + if (IS_ERR(np)) > + return PTR_ERR(np); > + > + if (!of_device_is_compatible(np, "operating-points-v2-kryo-cpu")) { > + of_node_put(np); > + return -ENOENT; > + } > + > + speedbin_nvmem = of_nvmem_cell_get(np, NULL); > + of_node_put(np); > + if (IS_ERR(speedbin_nvmem)) { > + dev_err(cpu_dev, "Could not get nvmem cell: %ld\n", > + PTR_ERR(speedbin_nvmem)); > + return PTR_ERR(speedbin_nvmem); > + } > + > + speedbin = nvmem_cell_read(speedbin_nvmem, &len); > + nvmem_cell_put(speedbin_nvmem); > + > + switch (msm8996_version) { > + case MSM8996_V3: > + versions = 1 << (unsigned int)(*speedbin); > + break; > + case MSM8996_SG: > + versions = 1 << ((unsigned int)(*speedbin) + 4); > + break; > + default: > + BUG(); > + break; > + } > + > + for_each_possible_cpu(cpu) { > + cpu_dev = get_cpu_device(cpu); > + if (NULL == cpu_dev) { > + ret = -ENODEV; > + goto free_opp; > + } > + > + opp_tables[cpu] = dev_pm_opp_set_supported_hw(cpu_dev, > + &versions, 1); > + if (IS_ERR(opp_tables[cpu])) { > + ret = PTR_ERR(opp_tables[cpu]); > + dev_err(cpu_dev, "Failed to set supported hardware\n"); > + goto free_opp; > + } > + } > + > + cpufreq_dt_pdev = platform_device_register_simple("cpufreq-dt", -1, > + NULL, 0); > + if (!IS_ERR(cpufreq_dt_pdev)) > + return 0; > + > + ret = PTR_ERR(cpufreq_dt_pdev); > + dev_err(cpu_dev, "Failed to register platform device\n"); > + > +free_opp: > + for_each_possible_cpu(cpu) { > + if (IS_ERR_OR_NULL(opp_tables[cpu])) > + break; > + dev_pm_opp_put_supported_hw(opp_tables[cpu]); > + } > + > + return ret; > +} > + > +static struct platform_driver qcom_cpufreq_kryo_driver = { > + .probe = qcom_cpufreq_kryo_probe, > + .driver = { > + .name = "qcom-cpufreq-kryo", > + }, > +}; > + > +/* > + * Since the driver depends on smem and nvmem drivers, which may > + * return EPROBE_DEFER, all the real activity is done in the probe, > + * which may be defered as well. The init here is only registering > + * the driver and the platform device. > + */ > +static int __init qcom_cpufreq_kryo_init(void) > +{ > + int ret; > + > + ret = platform_driver_register(&qcom_cpufreq_kryo_driver); > + if (unlikely(ret < 0)) > + return ret; > + > + ret = PTR_ERR_OR_ZERO(platform_device_register_simple( > + "qcom-cpufreq-kryo", -1, NULL, 0)); You simply can't do this unconditionally here. This will blow up on platforms where this driver is not supposed to work. The probe will be called on non-QCOM or non-Kryo QCOM platforms and I reckon it will crash trying to execute something in qcom_smem_get. -- Regards, Sudeep ^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: [PATCH v12 1/2] cpufreq: Add Kryo CPU scaling driver 2018-05-24 12:51 ` Sudeep Holla @ 2018-05-24 13:03 ` ilialin 2018-05-24 14:01 ` Sudeep Holla 0 siblings, 1 reply; 12+ messages in thread From: ilialin @ 2018-05-24 13:03 UTC (permalink / raw) To: 'Sudeep Holla', vireshk, nm, sboyd, robh, mark.rutland, rjw Cc: linux-pm, devicetree, linux-kernel > -----Original Message----- > From: Sudeep Holla <sudeep.holla@arm.com> > Sent: Thursday, May 24, 2018 15:52 > To: Ilia Lin <ilialin@codeaurora.org>; vireshk@kernel.org; nm@ti.com; > sboyd@kernel.org; robh@kernel.org; mark.rutland@arm.com; > rjw@rjwysocki.net > Cc: Sudeep Holla <sudeep.holla@arm.com>; linux-pm@vger.kernel.org; > devicetree@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: Re: [PATCH v12 1/2] cpufreq: Add Kryo CPU scaling driver > > Hi Ilia, > > > On 24/05/18 09:57, Ilia Lin wrote: > > In Certain QCOM SoCs like apq8096 and msm8996 that have KRYO > > processors, the CPU frequency subset and voltage value of each OPP > > varies based on the silicon variant in use. Qualcomm Process Voltage > > Scaling Tables defines the voltage and frequency value based on the > > msm-id in SMEM and speedbin blown in the efuse combination. > > The qcom-cpufreq-kryo driver reads the msm-id and efuse value from the > > SoC to provide the OPP framework with required information. > > This is used to determine the voltage and frequency value for each OPP > > of > > operating-points-v2 table when it is parsed by the OPP framework. > > > > Signed-off-by: Ilia Lin <ilialin@codeaurora.org> > > --- > > drivers/cpufreq/Kconfig.arm | 10 ++ > > drivers/cpufreq/Makefile | 1 + > > drivers/cpufreq/cpufreq-dt-platdev.c | 3 + > > drivers/cpufreq/qcom-cpufreq-kryo.c | 194 > > +++++++++++++++++++++++++++++++++++ > > 4 files changed, 208 insertions(+) > > create mode 100644 drivers/cpufreq/qcom-cpufreq-kryo.c > > > > diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm > > index de55c7d..0bfd40e 100644 > > --- a/drivers/cpufreq/Kconfig.arm > > +++ b/drivers/cpufreq/Kconfig.arm > > @@ -124,6 +124,16 @@ config ARM_OMAP2PLUS_CPUFREQ > > depends on ARCH_OMAP2PLUS > > default ARCH_OMAP2PLUS > > > > +config ARM_QCOM_CPUFREQ_KRYO > > + bool "Qualcomm Kryo based CPUFreq" > > + depends on QCOM_QFPROM > > + depends on QCOM_SMEM > > + select PM_OPP > > + help > > + This adds the CPUFreq driver for Qualcomm Kryo SoC based boards. > > + > > + If in doubt, say N. > > + > > config ARM_S3C_CPUFREQ > > bool > > help > > diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile index > > 8d24ade..fb4a2ec 100644 > > --- a/drivers/cpufreq/Makefile > > +++ b/drivers/cpufreq/Makefile > > @@ -65,6 +65,7 @@ obj-$(CONFIG_MACH_MVEBU_V7) += > mvebu-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_QCOM_CPUFREQ_KRYO) += qcom-cpufreq- > kryo.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/cpufreq-dt-platdev.c > > b/drivers/cpufreq/cpufreq-dt-platdev.c > > index 3b585e4..77d6ab8 100644 > > --- a/drivers/cpufreq/cpufreq-dt-platdev.c > > +++ b/drivers/cpufreq/cpufreq-dt-platdev.c > > @@ -118,6 +118,9 @@ > > > > { .compatible = "nvidia,tegra124", }, > > > > + { .compatible = "qcom,apq8096", }, > > + { .compatible = "qcom,msm8996", }, > > + > > { .compatible = "st,stih407", }, > > { .compatible = "st,stih410", }, > > > > diff --git a/drivers/cpufreq/qcom-cpufreq-kryo.c > > b/drivers/cpufreq/qcom-cpufreq-kryo.c > > new file mode 100644 > > index 0000000..9fe379c > > --- /dev/null > > +++ b/drivers/cpufreq/qcom-cpufreq-kryo.c > > @@ -0,0 +1,194 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +/* > > + * Copyright (c) 2018, The Linux Foundation. All rights reserved. > > + */ > > + > > +/* > > + * In Certain QCOM SoCs like apq8096 and msm8996 that have KRYO > > +processors, > > + * the CPU frequency subset and voltage value of each OPP varies > > + * based on the silicon variant in use. Qualcomm Process Voltage > > +Scaling Tables > > + * defines the voltage and frequency value based on the msm-id in > > +SMEM > > + * and speedbin blown in the efuse combination. > > + * The qcom-cpufreq-kryo driver reads the msm-id and efuse value from > > +the SoC > > + * to provide the OPP framework with required information. > > + * This is used to determine the voltage and frequency value for each > > +OPP of > > + * operating-points-v2 table when it is parsed by the OPP framework. > > + */ > > + > > +#include <linux/cpu.h> > > +#include <linux/err.h> > > +#include <linux/init.h> > > +#include <linux/kernel.h> > > +#include <linux/module.h> > > +#include <linux/nvmem-consumer.h> > > +#include <linux/of.h> > > +#include <linux/platform_device.h> > > +#include <linux/pm_opp.h> > > +#include <linux/slab.h> > > +#include <linux/soc/qcom/smem.h> > > + > > +#define MSM_ID_SMEM 137 > > + > > +enum _msm_id { > > + MSM8996V3 = 0xF6ul, > > + APQ8096V3 = 0x123ul, > > + MSM8996SG = 0x131ul, > > + APQ8096SG = 0x138ul, > > +}; > > + > > +enum _msm8996_version { > > + MSM8996_V3, > > + MSM8996_SG, > > + NUM_OF_MSM8996_VERSIONS, > > +}; > > + > > +static enum _msm8996_version __init > > +qcom_cpufreq_kryo_get_msm_id(void) > > +{ > > + size_t len; > > + u32 *msm_id; > > + enum _msm8996_version version; > > + > > + msm_id = qcom_smem_get(QCOM_SMEM_HOST_ANY, > MSM_ID_SMEM, &len); > > + /* The first 4 bytes are format, next to them is the actual msm-id */ > > + msm_id++; > > + > > + switch ((enum _msm_id)*msm_id) { > > + case MSM8996V3: > > + case APQ8096V3: > > + version = MSM8996_V3; > > + break; > > + case MSM8996SG: > > + case APQ8096SG: > > + version = MSM8996_SG; > > + break; > > + default: > > + version = NUM_OF_MSM8996_VERSIONS; > > + } > > + > > + return version; > > +} > > + > > +static int qcom_cpufreq_kryo_probe(struct platform_device *pdev) { > > + struct opp_table *opp_tables[NR_CPUS] = {0}; > > + struct platform_device *cpufreq_dt_pdev; > > + enum _msm8996_version msm8996_version; > > + struct nvmem_cell *speedbin_nvmem; > > + struct device_node *np; > > + struct device *cpu_dev; > > + unsigned cpu; > > + u8 *speedbin; > > + u32 versions; > > + size_t len; > > + int ret; > > + > > + cpu_dev = get_cpu_device(0); > > + if (NULL == cpu_dev) > > + return -ENODEV; > > + > > + msm8996_version = qcom_cpufreq_kryo_get_msm_id(); > > + if (NUM_OF_MSM8996_VERSIONS == msm8996_version) { > > + dev_err(cpu_dev, "Not Snapdragon 820/821!"); > > + return -ENODEV; > > + } > > + > > + np = dev_pm_opp_of_get_opp_desc_node(cpu_dev); > > + if (IS_ERR(np)) > > + return PTR_ERR(np); > > + > > + if (!of_device_is_compatible(np, "operating-points-v2-kryo-cpu")) { > > + of_node_put(np); > > + return -ENOENT; > > + } > > + > > + speedbin_nvmem = of_nvmem_cell_get(np, NULL); > > + of_node_put(np); > > + if (IS_ERR(speedbin_nvmem)) { > > + dev_err(cpu_dev, "Could not get nvmem cell: %ld\n", > > + PTR_ERR(speedbin_nvmem)); > > + return PTR_ERR(speedbin_nvmem); > > + } > > + > > + speedbin = nvmem_cell_read(speedbin_nvmem, &len); > > + nvmem_cell_put(speedbin_nvmem); > > + > > + switch (msm8996_version) { > > + case MSM8996_V3: > > + versions = 1 << (unsigned int)(*speedbin); > > + break; > > + case MSM8996_SG: > > + versions = 1 << ((unsigned int)(*speedbin) + 4); > > + break; > > + default: > > + BUG(); > > + break; > > + } > > + > > + for_each_possible_cpu(cpu) { > > + cpu_dev = get_cpu_device(cpu); > > + if (NULL == cpu_dev) { > > + ret = -ENODEV; > > + goto free_opp; > > + } > > + > > + opp_tables[cpu] = > dev_pm_opp_set_supported_hw(cpu_dev, > > + &versions, 1); > > + if (IS_ERR(opp_tables[cpu])) { > > + ret = PTR_ERR(opp_tables[cpu]); > > + dev_err(cpu_dev, "Failed to set supported > hardware\n"); > > + goto free_opp; > > + } > > + } > > + > > + cpufreq_dt_pdev = platform_device_register_simple("cpufreq-dt", - > 1, > > + NULL, 0); > > + if (!IS_ERR(cpufreq_dt_pdev)) > > + return 0; > > + > > + ret = PTR_ERR(cpufreq_dt_pdev); > > + dev_err(cpu_dev, "Failed to register platform device\n"); > > + > > +free_opp: > > + for_each_possible_cpu(cpu) { > > + if (IS_ERR_OR_NULL(opp_tables[cpu])) > > + break; > > + dev_pm_opp_put_supported_hw(opp_tables[cpu]); > > + } > > + > > + return ret; > > +} > > + > > +static struct platform_driver qcom_cpufreq_kryo_driver = { > > + .probe = qcom_cpufreq_kryo_probe, > > + .driver = { > > + .name = "qcom-cpufreq-kryo", > > + }, > > +}; > > + > > +/* > > + * Since the driver depends on smem and nvmem drivers, which may > > + * return EPROBE_DEFER, all the real activity is done in the probe, > > + * which may be defered as well. The init here is only registering > > + * the driver and the platform device. > > + */ > > +static int __init qcom_cpufreq_kryo_init(void) { > > + int ret; > > + > > + ret = platform_driver_register(&qcom_cpufreq_kryo_driver); > > + if (unlikely(ret < 0)) > > + return ret; > > + > > + ret = PTR_ERR_OR_ZERO(platform_device_register_simple( > > + "qcom-cpufreq-kryo", -1, NULL, 0)); > > > You simply can't do this unconditionally here. This will blow up on platforms > where this driver is not supposed to work. The probe will be called on non- > QCOM or non-Kryo QCOM platforms and I reckon it will crash trying to > execute something in qcom_smem_get. What do you mean by 'unconditionally'? The driver depends on the smem and nvmem drivers, which depend on ARCH_QCOM: + depends on QCOM_QFPROM + depends on QCOM_SMEM And if SMEM read in the probe returns something other than Kryo, it will exit. > > -- > Regards, > Sudeep ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v12 1/2] cpufreq: Add Kryo CPU scaling driver 2018-05-24 13:03 ` ilialin @ 2018-05-24 14:01 ` Sudeep Holla 2018-05-24 14:10 ` ilialin 0 siblings, 1 reply; 12+ messages in thread From: Sudeep Holla @ 2018-05-24 14:01 UTC (permalink / raw) To: ilialin, vireshk, nm, sboyd, robh, mark.rutland, rjw Cc: Sudeep Holla, linux-pm, devicetree, linux-kernel On 24/05/18 14:03, ilialin@codeaurora.org wrote: > > [...] >>> + >>> + ret = PTR_ERR_OR_ZERO(platform_device_register_simple( >>> + "qcom-cpufreq-kryo", -1, NULL, 0)); >> >> >> You simply can't do this unconditionally here. This will blow up on platforms >> where this driver is not supposed to work. The probe will be called on non- >> QCOM or non-Kryo QCOM platforms and I reckon it will crash trying to >> execute something in qcom_smem_get. > > What do you mean by 'unconditionally'? Why should you even add/register a device "qcom-cpufreq-kryo" on other platforms. Drivers can get registered, but only devices that are present or required by the platform need to be registered. > The driver depends on the smem and nvmem drivers, which depend on ARCH_QCOM: > + depends on QCOM_QFPROM > + depends on QCOM_SMEM > Sure, but we have something called single image for all ARM64 platforms. May be QCOM still used to tweeking config to build binary for your particular mobile platform but the distro kernel need single binary to work on all platforms. We have moved far away from platform specific builds long back now IIRC. > And if SMEM read in the probe returns something other than Kryo, it will exit. > Check what this driver does ? msm_id = qcom_smem_get(QCOM_SMEM_HOST_ANY, MSM_ID_SMEM, &len); msm_id++; switch ((enum _msm_id)*msm_id) I think it *will and should* crash here ? You need to check the return value for sure. But since qcom_smem_get return -EPROBE_DEFER, we keep retrying even on non QCOM platforms which is something I would like to avoid. Therefore that's not the main concern. Why do I have to see "qcom-cpufreq-kryo" device registered on my non QCOM platform ? -- Regards, Sudeep ^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: [PATCH v12 1/2] cpufreq: Add Kryo CPU scaling driver 2018-05-24 14:01 ` Sudeep Holla @ 2018-05-24 14:10 ` ilialin 2018-05-24 14:47 ` Sudeep Holla 0 siblings, 1 reply; 12+ messages in thread From: ilialin @ 2018-05-24 14:10 UTC (permalink / raw) To: 'Sudeep Holla' Cc: linux-pm, devicetree, linux-kernel, vireshk, nm, sboyd, robh, mark.rutland, rjw Thank you for the explanation. However, could you suggest, which condition should I check then? Device tree? > -----Original Message----- > From: Sudeep Holla <sudeep.holla@arm.com> > Sent: Thursday, May 24, 2018 17:01 > To: ilialin@codeaurora.org; vireshk@kernel.org; nm@ti.com; > sboyd@kernel.org; robh@kernel.org; mark.rutland@arm.com; > rjw@rjwysocki.net > Cc: Sudeep Holla <sudeep.holla@arm.com>; linux-pm@vger.kernel.org; > devicetree@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: Re: [PATCH v12 1/2] cpufreq: Add Kryo CPU scaling driver > > > > On 24/05/18 14:03, ilialin@codeaurora.org wrote: > > > > > > [...] > > >>> + > >>> + ret = PTR_ERR_OR_ZERO(platform_device_register_simple( > >>> + "qcom-cpufreq-kryo", -1, NULL, 0)); > >> > >> > >> You simply can't do this unconditionally here. This will blow up on > >> platforms where this driver is not supposed to work. The probe will > >> be called on non- QCOM or non-Kryo QCOM platforms and I reckon it > >> will crash trying to execute something in qcom_smem_get. > > > > What do you mean by 'unconditionally'? > > Why should you even add/register a device "qcom-cpufreq-kryo" on other > platforms. Drivers can get registered, but only devices that are present or > required by the platform need to be registered. > > > The driver depends on the smem and nvmem drivers, which depend on > ARCH_QCOM: > > + depends on QCOM_QFPROM > > + depends on QCOM_SMEM > > > > Sure, but we have something called single image for all ARM64 platforms. > May be QCOM still used to tweeking config to build binary for your particular > mobile platform but the distro kernel need single binary to work on all > platforms. We have moved far away from platform specific builds long back > now IIRC. > > > And if SMEM read in the probe returns something other than Kryo, it will > exit. > > > > Check what this driver does ? > > msm_id = qcom_smem_get(QCOM_SMEM_HOST_ANY, > MSM_ID_SMEM, &len); > msm_id++; > switch ((enum _msm_id)*msm_id) > > I think it *will and should* crash here ? You need to check the return value > for sure. But since qcom_smem_get return -EPROBE_DEFER, we keep > retrying even on non QCOM platforms which is something I would like to > avoid. > > Therefore that's not the main concern. Why do I have to see "qcom-cpufreq- > kryo" device registered on my non QCOM platform ? > > -- > Regards, > Sudeep ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v12 1/2] cpufreq: Add Kryo CPU scaling driver 2018-05-24 14:10 ` ilialin @ 2018-05-24 14:47 ` Sudeep Holla 2018-05-24 14:52 ` ilialin 0 siblings, 1 reply; 12+ messages in thread From: Sudeep Holla @ 2018-05-24 14:47 UTC (permalink / raw) To: ilialin Cc: Sudeep Holla, linux-pm, devicetree, linux-kernel, vireshk, nm, sboyd, robh, mark.rutland, rjw On 24/05/18 15:10, ilialin@codeaurora.org wrote: > Thank you for the explanation. However, could you suggest, which > condition should I check then? Device tree? > Yes some compatible which is applicable for all the SoCs or platforms on which this driver can work ? -- Regards, Sudeep ^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: [PATCH v12 1/2] cpufreq: Add Kryo CPU scaling driver 2018-05-24 14:47 ` Sudeep Holla @ 2018-05-24 14:52 ` ilialin 2018-05-24 15:02 ` Sudeep Holla 0 siblings, 1 reply; 12+ messages in thread From: ilialin @ 2018-05-24 14:52 UTC (permalink / raw) To: 'Sudeep Holla' Cc: linux-pm, devicetree, linux-kernel, vireshk, nm, sboyd, robh, mark.rutland, rjw OK, got you. Is "operating-points-v2-kryo-cpu" good enough? > -----Original Message----- > From: Sudeep Holla <sudeep.holla@arm.com> > Sent: Thursday, May 24, 2018 17:48 > To: ilialin@codeaurora.org > Cc: Sudeep Holla <sudeep.holla@arm.com>; linux-pm@vger.kernel.org; > devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; > vireshk@kernel.org; nm@ti.com; sboyd@kernel.org; robh@kernel.org; > mark.rutland@arm.com; rjw@rjwysocki.net > Subject: Re: [PATCH v12 1/2] cpufreq: Add Kryo CPU scaling driver > > > > On 24/05/18 15:10, ilialin@codeaurora.org wrote: > > Thank you for the explanation. However, could you suggest, which > > condition should I check then? Device tree? > > > > Yes some compatible which is applicable for all the SoCs or platforms on > which this driver can work ? > > -- > Regards, > Sudeep ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v12 1/2] cpufreq: Add Kryo CPU scaling driver 2018-05-24 14:52 ` ilialin @ 2018-05-24 15:02 ` Sudeep Holla 0 siblings, 0 replies; 12+ messages in thread From: Sudeep Holla @ 2018-05-24 15:02 UTC (permalink / raw) To: ilialin Cc: Sudeep Holla, linux-pm, devicetree, linux-kernel, vireshk, nm, sboyd, robh, mark.rutland, rjw On 24/05/18 15:52, ilialin@codeaurora.org wrote: > OK, got you. > Is "operating-points-v2-kryo-cpu" good enough? > Not sure if I can answer that as I don't have full knowledge on PM on all Kryo CPUs. Will this driver work on all those platforms which will have "operating-points-v2-kryo-cpu" ? If yes, then go ahead. I would prefer using some compatible in the CPU node rather that OPP, but that's just my opinion. Check with other QCOM guys on the list who have worked on CPUFreq or still working.(Taniya, Saravana, S Boyd, ...?) -- Regards, Sudeep ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH v12 2/2] dt-bindings: cpufreq: Document operating-points-v2-kryo-cpu 2018-05-24 8:57 [PATCH v12 0/2] Kryo CPU scaling driver Ilia Lin 2018-05-24 8:57 ` [PATCH v12 1/2] cpufreq: Add " Ilia Lin @ 2018-05-24 8:57 ` Ilia Lin 2018-05-24 9:02 ` [PATCH v12 0/2] Kryo CPU scaling driver Viresh Kumar 2018-05-24 11:20 ` Amit Kucheria 3 siblings, 0 replies; 12+ messages in thread From: Ilia Lin @ 2018-05-24 8:57 UTC (permalink / raw) To: vireshk, nm, sboyd, robh, mark.rutland, rjw Cc: linux-pm, devicetree, linux-kernel, ilialin The qcom-cpufreq-kryo driver reads the msm-id and efuse value from the SoC to provide the OPP framework with required information. This is used to determine the voltage and frequency value for each OPP of operating-points-v2 table when it is parsed by the OPP framework. This change adds documentation for the DT bindings. The "operating-points-v2-kryo-cpu" DT extends the "operating-points-v2" with following parameters: - nvmem-cells (NVMEM area containig the speedbin information) - opp-supported-hw: A single 32 bit bitmap value, representing compatible HW: 0: MSM8996 V3, speedbin 0 1: MSM8996 V3, speedbin 1 2: MSM8996 V3, speedbin 2 3: unused 4: MSM8996 SG, speedbin 0 5: MSM8996 SG, speedbin 1 6: MSM8996 SG, speedbin 2 7-31: unused Signed-off-by: Ilia Lin <ilialin@codeaurora.org> Reviewed-by: Rob Herring <robh@kernel.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> --- .../devicetree/bindings/opp/kryo-cpufreq.txt | 680 +++++++++++++++++++++ 1 file changed, 680 insertions(+) create mode 100644 Documentation/devicetree/bindings/opp/kryo-cpufreq.txt diff --git a/Documentation/devicetree/bindings/opp/kryo-cpufreq.txt b/Documentation/devicetree/bindings/opp/kryo-cpufreq.txt new file mode 100644 index 0000000..c2127b9 --- /dev/null +++ b/Documentation/devicetree/bindings/opp/kryo-cpufreq.txt @@ -0,0 +1,680 @@ +Qualcomm Technologies, Inc. KRYO CPUFreq and OPP bindings +=================================== + +In Certain Qualcomm Technologies, Inc. SoCs like apq8096 and msm8996 +that have KRYO processors, the CPU ferequencies subset and voltage value +of each OPP varies based on the silicon variant in use. +Qualcomm Technologies, Inc. Process Voltage Scaling Tables +defines the voltage and frequency value based on the msm-id in SMEM +and speedbin blown in the efuse combination. +The qcom-cpufreq-kryo driver reads the msm-id and efuse value from the SoC +to provide the OPP framework with required information (existing HW bitmap). +This is used to determine the voltage and frequency value for each OPP of +operating-points-v2 table when it is parsed by the OPP framework. + +Required properties: +-------------------- +In 'cpus' nodes: +- operating-points-v2: Phandle to the operating-points-v2 table to use. + +In 'operating-points-v2' table: +- compatible: Should be + - 'operating-points-v2-kryo-cpu' for apq8096 and msm8996. +- nvmem-cells: A phandle pointing to a nvmem-cells node representing the + efuse registers that has information about the + speedbin that is used to select the right frequency/voltage + value pair. + Please refer the for nvmem-cells + bindings Documentation/devicetree/bindings/nvmem/nvmem.txt + and also examples below. + +In every OPP node: +- opp-supported-hw: A single 32 bit bitmap value, representing compatible HW. + Bitmap: + 0: MSM8996 V3, speedbin 0 + 1: MSM8996 V3, speedbin 1 + 2: MSM8996 V3, speedbin 2 + 3: unused + 4: MSM8996 SG, speedbin 0 + 5: MSM8996 SG, speedbin 1 + 6: MSM8996 SG, speedbin 2 + 7-31: unused + +Example 1: +--------- + + cpus { + #address-cells = <2>; + #size-cells = <0>; + + CPU0: cpu@0 { + device_type = "cpu"; + compatible = "qcom,kryo"; + reg = <0x0 0x0>; + enable-method = "psci"; + clocks = <&kryocc 0>; + cpu-supply = <&pm8994_s11_saw>; + operating-points-v2 = <&cluster0_opp>; + #cooling-cells = <2>; + next-level-cache = <&L2_0>; + L2_0: l2-cache { + compatible = "cache"; + cache-level = <2>; + }; + }; + + CPU1: cpu@1 { + device_type = "cpu"; + compatible = "qcom,kryo"; + reg = <0x0 0x1>; + enable-method = "psci"; + clocks = <&kryocc 0>; + cpu-supply = <&pm8994_s11_saw>; + operating-points-v2 = <&cluster0_opp>; + #cooling-cells = <2>; + next-level-cache = <&L2_0>; + }; + + CPU2: cpu@100 { + device_type = "cpu"; + compatible = "qcom,kryo"; + reg = <0x0 0x100>; + enable-method = "psci"; + clocks = <&kryocc 1>; + cpu-supply = <&pm8994_s11_saw>; + operating-points-v2 = <&cluster1_opp>; + #cooling-cells = <2>; + next-level-cache = <&L2_1>; + L2_1: l2-cache { + compatible = "cache"; + cache-level = <2>; + }; + }; + + CPU3: cpu@101 { + device_type = "cpu"; + compatible = "qcom,kryo"; + reg = <0x0 0x101>; + enable-method = "psci"; + clocks = <&kryocc 1>; + cpu-supply = <&pm8994_s11_saw>; + operating-points-v2 = <&cluster1_opp>; + #cooling-cells = <2>; + next-level-cache = <&L2_1>; + }; + + cpu-map { + cluster0 { + core0 { + cpu = <&CPU0>; + }; + + core1 { + cpu = <&CPU1>; + }; + }; + + cluster1 { + core0 { + cpu = <&CPU2>; + }; + + core1 { + cpu = <&CPU3>; + }; + }; + }; + }; + + cluster0_opp: opp_table0 { + compatible = "operating-points-v2-kryo-cpu"; + nvmem-cells = <&speedbin_efuse>; + opp-shared; + + opp-307200000 { + opp-hz = /bits/ 64 <307200000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x77>; + clock-latency-ns = <200000>; + }; + opp-384000000 { + opp-hz = /bits/ 64 <384000000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-422400000 { + opp-hz = /bits/ 64 <422400000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x7>; + clock-latency-ns = <200000>; + }; + opp-460800000 { + opp-hz = /bits/ 64 <460800000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-480000000 { + opp-hz = /bits/ 64 <480000000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x7>; + clock-latency-ns = <200000>; + }; + opp-537600000 { + opp-hz = /bits/ 64 <537600000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-556800000 { + opp-hz = /bits/ 64 <556800000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x7>; + clock-latency-ns = <200000>; + }; + opp-614400000 { + opp-hz = /bits/ 64 <614400000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-652800000 { + opp-hz = /bits/ 64 <652800000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x7>; + clock-latency-ns = <200000>; + }; + opp-691200000 { + opp-hz = /bits/ 64 <691200000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-729600000 { + opp-hz = /bits/ 64 <729600000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x7>; + clock-latency-ns = <200000>; + }; + opp-768000000 { + opp-hz = /bits/ 64 <768000000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-844800000 { + opp-hz = /bits/ 64 <844800000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x77>; + clock-latency-ns = <200000>; + }; + opp-902400000 { + opp-hz = /bits/ 64 <902400000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-960000000 { + opp-hz = /bits/ 64 <960000000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x7>; + clock-latency-ns = <200000>; + }; + opp-979200000 { + opp-hz = /bits/ 64 <979200000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-1036800000 { + opp-hz = /bits/ 64 <1036800000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x7>; + clock-latency-ns = <200000>; + }; + opp-1056000000 { + opp-hz = /bits/ 64 <1056000000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-1113600000 { + opp-hz = /bits/ 64 <1113600000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x7>; + clock-latency-ns = <200000>; + }; + opp-1132800000 { + opp-hz = /bits/ 64 <1132800000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-1190400000 { + opp-hz = /bits/ 64 <1190400000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x7>; + clock-latency-ns = <200000>; + }; + opp-1209600000 { + opp-hz = /bits/ 64 <1209600000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-1228800000 { + opp-hz = /bits/ 64 <1228800000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x7>; + clock-latency-ns = <200000>; + }; + opp-1286400000 { + opp-hz = /bits/ 64 <1286400000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-1324800000 { + opp-hz = /bits/ 64 <1324800000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x5>; + clock-latency-ns = <200000>; + }; + opp-1363200000 { + opp-hz = /bits/ 64 <1363200000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x72>; + clock-latency-ns = <200000>; + }; + opp-1401600000 { + opp-hz = /bits/ 64 <1401600000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x5>; + clock-latency-ns = <200000>; + }; + opp-1440000000 { + opp-hz = /bits/ 64 <1440000000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-1478400000 { + opp-hz = /bits/ 64 <1478400000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x1>; + clock-latency-ns = <200000>; + }; + opp-1497600000 { + opp-hz = /bits/ 64 <1497600000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x4>; + clock-latency-ns = <200000>; + }; + opp-1516800000 { + opp-hz = /bits/ 64 <1516800000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-1593600000 { + opp-hz = /bits/ 64 <1593600000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x71>; + clock-latency-ns = <200000>; + }; + opp-1996800000 { + opp-hz = /bits/ 64 <1996800000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x20>; + clock-latency-ns = <200000>; + }; + opp-2188800000 { + opp-hz = /bits/ 64 <2188800000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x10>; + clock-latency-ns = <200000>; + }; + }; + + cluster1_opp: opp_table1 { + compatible = "operating-points-v2-kryo-cpu"; + nvmem-cells = <&speedbin_efuse>; + opp-shared; + + opp-307200000 { + opp-hz = /bits/ 64 <307200000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x77>; + clock-latency-ns = <200000>; + }; + opp-384000000 { + opp-hz = /bits/ 64 <384000000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-403200000 { + opp-hz = /bits/ 64 <403200000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x7>; + clock-latency-ns = <200000>; + }; + opp-460800000 { + opp-hz = /bits/ 64 <460800000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-480000000 { + opp-hz = /bits/ 64 <480000000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x7>; + clock-latency-ns = <200000>; + }; + opp-537600000 { + opp-hz = /bits/ 64 <537600000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-556800000 { + opp-hz = /bits/ 64 <556800000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x7>; + clock-latency-ns = <200000>; + }; + opp-614400000 { + opp-hz = /bits/ 64 <614400000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-652800000 { + opp-hz = /bits/ 64 <652800000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x7>; + clock-latency-ns = <200000>; + }; + opp-691200000 { + opp-hz = /bits/ 64 <691200000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-729600000 { + opp-hz = /bits/ 64 <729600000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x7>; + clock-latency-ns = <200000>; + }; + opp-748800000 { + opp-hz = /bits/ 64 <748800000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-806400000 { + opp-hz = /bits/ 64 <806400000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x7>; + clock-latency-ns = <200000>; + }; + opp-825600000 { + opp-hz = /bits/ 64 <825600000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-883200000 { + opp-hz = /bits/ 64 <883200000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x7>; + clock-latency-ns = <200000>; + }; + opp-902400000 { + opp-hz = /bits/ 64 <902400000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-940800000 { + opp-hz = /bits/ 64 <940800000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x7>; + clock-latency-ns = <200000>; + }; + opp-979200000 { + opp-hz = /bits/ 64 <979200000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-1036800000 { + opp-hz = /bits/ 64 <1036800000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x7>; + clock-latency-ns = <200000>; + }; + opp-1056000000 { + opp-hz = /bits/ 64 <1056000000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-1113600000 { + opp-hz = /bits/ 64 <1113600000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x7>; + clock-latency-ns = <200000>; + }; + opp-1132800000 { + opp-hz = /bits/ 64 <1132800000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-1190400000 { + opp-hz = /bits/ 64 <1190400000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x7>; + clock-latency-ns = <200000>; + }; + opp-1209600000 { + opp-hz = /bits/ 64 <1209600000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-1248000000 { + opp-hz = /bits/ 64 <1248000000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x7>; + clock-latency-ns = <200000>; + }; + opp-1286400000 { + opp-hz = /bits/ 64 <1286400000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-1324800000 { + opp-hz = /bits/ 64 <1324800000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x7>; + clock-latency-ns = <200000>; + }; + opp-1363200000 { + opp-hz = /bits/ 64 <1363200000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-1401600000 { + opp-hz = /bits/ 64 <1401600000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x7>; + clock-latency-ns = <200000>; + }; + opp-1440000000 { + opp-hz = /bits/ 64 <1440000000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-1478400000 { + opp-hz = /bits/ 64 <1478400000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x7>; + clock-latency-ns = <200000>; + }; + opp-1516800000 { + opp-hz = /bits/ 64 <1516800000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-1555200000 { + opp-hz = /bits/ 64 <1555200000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x7>; + clock-latency-ns = <200000>; + }; + opp-1593600000 { + opp-hz = /bits/ 64 <1593600000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-1632000000 { + opp-hz = /bits/ 64 <1632000000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x7>; + clock-latency-ns = <200000>; + }; + opp-1670400000 { + opp-hz = /bits/ 64 <1670400000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-1708800000 { + opp-hz = /bits/ 64 <1708800000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x7>; + clock-latency-ns = <200000>; + }; + opp-1747200000 { + opp-hz = /bits/ 64 <1747200000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-1785600000 { + opp-hz = /bits/ 64 <1785600000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x7>; + clock-latency-ns = <200000>; + }; + opp-1804800000 { + opp-hz = /bits/ 64 <1804800000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x6>; + clock-latency-ns = <200000>; + }; + opp-1824000000 { + opp-hz = /bits/ 64 <1824000000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x71>; + clock-latency-ns = <200000>; + }; + opp-1900800000 { + opp-hz = /bits/ 64 <1900800000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x74>; + clock-latency-ns = <200000>; + }; + opp-1920000000 { + opp-hz = /bits/ 64 <1920000000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x1>; + clock-latency-ns = <200000>; + }; + opp-1977600000 { + opp-hz = /bits/ 64 <1977600000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x30>; + clock-latency-ns = <200000>; + }; + opp-1996800000 { + opp-hz = /bits/ 64 <1996800000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x1>; + clock-latency-ns = <200000>; + }; + opp-2054400000 { + opp-hz = /bits/ 64 <2054400000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x30>; + clock-latency-ns = <200000>; + }; + opp-2073600000 { + opp-hz = /bits/ 64 <2073600000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x1>; + clock-latency-ns = <200000>; + }; + opp-2150400000 { + opp-hz = /bits/ 64 <2150400000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x31>; + clock-latency-ns = <200000>; + }; + opp-2246400000 { + opp-hz = /bits/ 64 <2246400000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x10>; + clock-latency-ns = <200000>; + }; + opp-2342400000 { + opp-hz = /bits/ 64 <2342400000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x10>; + clock-latency-ns = <200000>; + }; + }; + +.... + +reserved-memory { + #address-cells = <2>; + #size-cells = <2>; + ranges; +.... + smem_mem: smem-mem@86000000 { + reg = <0x0 0x86000000 0x0 0x200000>; + no-map; + }; +.... +}; + +smem { + compatible = "qcom,smem"; + memory-region = <&smem_mem>; + hwlocks = <&tcsr_mutex 3>; +}; + +soc { +.... + qfprom: qfprom@74000 { + compatible = "qcom,qfprom"; + reg = <0x00074000 0x8ff>; + #address-cells = <1>; + #size-cells = <1>; + .... + speedbin_efuse: speedbin@133 { + reg = <0x133 0x1>; + bits = <5 3>; + }; + }; +}; -- 1.9.1 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH v12 0/2] Kryo CPU scaling driver 2018-05-24 8:57 [PATCH v12 0/2] Kryo CPU scaling driver Ilia Lin 2018-05-24 8:57 ` [PATCH v12 1/2] cpufreq: Add " Ilia Lin 2018-05-24 8:57 ` [PATCH v12 2/2] dt-bindings: cpufreq: Document operating-points-v2-kryo-cpu Ilia Lin @ 2018-05-24 9:02 ` Viresh Kumar 2018-05-24 11:20 ` Amit Kucheria 3 siblings, 0 replies; 12+ messages in thread From: Viresh Kumar @ 2018-05-24 9:02 UTC (permalink / raw) To: Ilia Lin Cc: vireshk, nm, sboyd, robh, mark.rutland, rjw, linux-pm, devicetree, linux-kernel On 24-05-18, 11:57, Ilia Lin wrote: > [v12] > * Addressed comments from Sudeep and Viresh about the single init > > [v11] > * Addressed comment from Russel about device_node reference > * Addressed comment from Sudeep about the late_initcall > * Transformed init into probe to take care of deferals > > [v10] > * Split the series into domains > * Addressed comments from Viresh and Sudeep about logical CPU numbering. > > The qcom-cpufreq-kryo driver is aimed to support different SOC versions. > The driver reads eFuse information and chooses the required OPP subset > by passing the OPP supported-hw parameter. > > The series depends on the series from Viresh: > https://patchwork.kernel.org/patch/10418139/ > > The previous spin was here: > https://patchwork.kernel.org/patch/10421143/ Acked-by: Viresh Kumar <viresh.kumar@linaro.org> -- viresh ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v12 0/2] Kryo CPU scaling driver 2018-05-24 8:57 [PATCH v12 0/2] Kryo CPU scaling driver Ilia Lin ` (2 preceding siblings ...) 2018-05-24 9:02 ` [PATCH v12 0/2] Kryo CPU scaling driver Viresh Kumar @ 2018-05-24 11:20 ` Amit Kucheria 3 siblings, 0 replies; 12+ messages in thread From: Amit Kucheria @ 2018-05-24 11:20 UTC (permalink / raw) To: Ilia Lin Cc: vireshk, nm, sboyd, Rob Herring, Mark Rutland, Rafael J. Wysocki, Linux PM list, devicetree, LKML On Thu, May 24, 2018 at 11:57 AM, Ilia Lin <ilialin@codeaurora.org> wrote: > [v12] > * Addressed comments from Sudeep and Viresh about the single init > > [v11] > * Addressed comment from Russel about device_node reference > * Addressed comment from Sudeep about the late_initcall > * Transformed init into probe to take care of deferals > > [v10] > * Split the series into domains > * Addressed comments from Viresh and Sudeep about logical CPU numbering. > > The qcom-cpufreq-kryo driver is aimed to support different SOC versions. > The driver reads eFuse information and chooses the required OPP subset > by passing the OPP supported-hw parameter. > > The series depends on the series from Viresh: > https://patchwork.kernel.org/patch/10418139/ > > The previous spin was here: > https://patchwork.kernel.org/patch/10421143/ > > Ilia Lin (2): > cpufreq: Add Kryo CPU scaling driver > dt-bindings: cpufreq: Document operating-points-v2-kryo-cpu > > .../devicetree/bindings/opp/kryo-cpufreq.txt | 680 +++++++++++++++++++++ > drivers/cpufreq/Kconfig.arm | 10 + > drivers/cpufreq/Makefile | 1 + > drivers/cpufreq/cpufreq-dt-platdev.c | 3 + > drivers/cpufreq/qcom-cpufreq-kryo.c | 194 ++++++ > 5 files changed, 888 insertions(+) > create mode 100644 Documentation/devicetree/bindings/opp/kryo-cpufreq.txt > create mode 100644 drivers/cpufreq/qcom-cpufreq-kryo.c > > -- > 1.9.1 > For this series, Reviewed-by: Amit Kucheria <amit.kucheria@linaro.org> Tested-by: Amit Kucheria <amit.kucheria@linaro.org> ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2018-05-24 15:02 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2018-05-24 8:57 [PATCH v12 0/2] Kryo CPU scaling driver Ilia Lin 2018-05-24 8:57 ` [PATCH v12 1/2] cpufreq: Add " Ilia Lin 2018-05-24 12:51 ` Sudeep Holla 2018-05-24 13:03 ` ilialin 2018-05-24 14:01 ` Sudeep Holla 2018-05-24 14:10 ` ilialin 2018-05-24 14:47 ` Sudeep Holla 2018-05-24 14:52 ` ilialin 2018-05-24 15:02 ` Sudeep Holla 2018-05-24 8:57 ` [PATCH v12 2/2] dt-bindings: cpufreq: Document operating-points-v2-kryo-cpu Ilia Lin 2018-05-24 9:02 ` [PATCH v12 0/2] Kryo CPU scaling driver Viresh Kumar 2018-05-24 11:20 ` Amit Kucheria
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).