* [PATCH v7] cpufreq: mediatek-hw: Add support for Mediatek cpufreq HW driver
@ 2020-09-10 4:31 Hector Yuan
2020-09-10 4:31 ` [PATCH v7 1/2] " Hector Yuan
` (2 more replies)
0 siblings, 3 replies; 16+ messages in thread
From: Hector Yuan @ 2020-09-10 4:31 UTC (permalink / raw)
To: linux-mediatek, linux-arm-kernel, linux-pm, devicetree,
Rafael J. Wysocki, Viresh Kumar, Rob Herring
Cc: linux-kernel, wsd_upstream, hector.yuan
The CPUfreq HW present in some Mediatek chipsets offloads the steps necessary for changing the frequency of CPUs.
The driver implements the cpufreq driver interface for this hardware engine.
This patch depends on the MT6779 DTS patch submitted by Hanks Chen
https://lkml.org/lkml/2020/8/4/1094
Hector.Yuan (2):
cpufreq: mediatek-hw: Add support for Mediatek cpufreq HW driver
dt-bindings: cpufreq: add bindings for MediaTek cpufreq HW
.../bindings/cpufreq/cpufreq-mediatek-hw.yaml | 141 ++++++++++
drivers/cpufreq/Kconfig.arm | 12 +
drivers/cpufreq/Makefile | 1 +
drivers/cpufreq/mediatek-cpufreq-hw.c | 277 ++++++++++++++++++++
4 files changed, 431 insertions(+)
create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml
create mode 100644 drivers/cpufreq/mediatek-cpufreq-hw.c
^ permalink raw reply [flat|nested] 16+ messages in thread* [PATCH v7 1/2] cpufreq: mediatek-hw: Add support for Mediatek cpufreq HW driver 2020-09-10 4:31 [PATCH v7] cpufreq: mediatek-hw: Add support for Mediatek cpufreq HW driver Hector Yuan @ 2020-09-10 4:31 ` Hector Yuan 2020-09-10 4:31 ` [PATCH v7 2/2] dt-bindings: cpufreq: add bindings for MediaTek cpufreq HW Hector Yuan 2020-09-10 5:03 ` [PATCH v7] cpufreq: mediatek-hw: Add support for Mediatek cpufreq HW driver Viresh Kumar 2 siblings, 0 replies; 16+ messages in thread From: Hector Yuan @ 2020-09-10 4:31 UTC (permalink / raw) To: linux-mediatek, linux-arm-kernel, linux-pm, devicetree, Rafael J. Wysocki, Viresh Kumar, Rob Herring Cc: linux-kernel, wsd_upstream, hector.yuan From: "Hector.Yuan" <hector.yuan@mediatek.com> Add MT6779 cpufreq HW support. Signed-off-by: Hector.Yuan <hector.yuan@mediatek.com> --- drivers/cpufreq/Kconfig.arm | 12 ++ drivers/cpufreq/Makefile | 1 + drivers/cpufreq/mediatek-cpufreq-hw.c | 277 +++++++++++++++++++++++++++++++++ 3 files changed, 290 insertions(+) create mode 100644 drivers/cpufreq/mediatek-cpufreq-hw.c diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm index c6cbfc8..8e58c12 100644 --- a/drivers/cpufreq/Kconfig.arm +++ b/drivers/cpufreq/Kconfig.arm @@ -121,6 +121,18 @@ config ARM_MEDIATEK_CPUFREQ help This adds the CPUFreq driver support for MediaTek SoCs. +config ARM_MEDIATEK_CPUFREQ_HW + tristate "MediaTek CPUFreq HW driver" + depends on ARCH_MEDIATEK || COMPILE_TEST + default m + help + Support for the CPUFreq HW driver. + Some MediaTek chipsets have a HW engine to offload the steps + necessary for changing the frequency of the CPUs. Firmware loaded + in this engine exposes a programming interface to the OS. + The driver implements the cpufreq interface for this HW engine. + Say Y if you want to support CPUFreq HW. + config ARM_OMAP2PLUS_CPUFREQ bool "TI OMAP2+" depends on ARCH_OMAP2PLUS diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile index f6670c4..dc1f371 100644 --- a/drivers/cpufreq/Makefile +++ b/drivers/cpufreq/Makefile @@ -57,6 +57,7 @@ obj-$(CONFIG_ARM_IMX6Q_CPUFREQ) += imx6q-cpufreq.o obj-$(CONFIG_ARM_IMX_CPUFREQ_DT) += imx-cpufreq-dt.o obj-$(CONFIG_ARM_KIRKWOOD_CPUFREQ) += kirkwood-cpufreq.o obj-$(CONFIG_ARM_MEDIATEK_CPUFREQ) += mediatek-cpufreq.o +obj-$(CONFIG_ARM_MEDIATEK_CPUFREQ_HW) += mediatek-cpufreq-hw.o obj-$(CONFIG_MACH_MVEBU_V7) += mvebu-cpufreq.o obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ) += omap-cpufreq.o obj-$(CONFIG_ARM_PXA2xx_CPUFREQ) += pxa2xx-cpufreq.o diff --git a/drivers/cpufreq/mediatek-cpufreq-hw.c b/drivers/cpufreq/mediatek-cpufreq-hw.c new file mode 100644 index 0000000..8fa12e5 --- /dev/null +++ b/drivers/cpufreq/mediatek-cpufreq-hw.c @@ -0,0 +1,277 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (c) 2020 MediaTek Inc. + */ + +#include <linux/bitfield.h> +#include <linux/cpufreq.h> +#include <linux/init.h> +#include <linux/kernel.h> +#include <linux/module.h> +#include <linux/of_address.h> +#include <linux/of_platform.h> +#include <linux/slab.h> + +#define LUT_MAX_ENTRIES 32U +#define LUT_FREQ GENMASK(11, 0) +#define LUT_ROW_SIZE 0x4 + +enum { + REG_LUT_TABLE, + REG_ENABLE, + REG_PERF_STATE, + + REG_ARRAY_SIZE, +}; + +struct cpufreq_mtk { + struct cpufreq_frequency_table *table; + void __iomem *reg_bases[REG_ARRAY_SIZE]; + cpumask_t related_cpus; +}; + +static const u16 cpufreq_mtk_offsets[REG_ARRAY_SIZE] = { + [REG_LUT_TABLE] = 0x0, + [REG_ENABLE] = 0x84, + [REG_PERF_STATE] = 0x88, +}; + +static struct cpufreq_mtk *mtk_freq_domain_map[NR_CPUS]; + +static int mtk_cpufreq_hw_target_index(struct cpufreq_policy *policy, + unsigned int index) +{ + struct cpufreq_mtk *c = policy->driver_data; + + writel_relaxed(index, c->reg_bases[REG_PERF_STATE]); + + return 0; +} + +static unsigned int mtk_cpufreq_hw_get(unsigned int cpu) +{ + struct cpufreq_mtk *c; + unsigned int index; + + c = mtk_freq_domain_map[cpu]; + + index = readl_relaxed(c->reg_bases[REG_PERF_STATE]); + index = min(index, LUT_MAX_ENTRIES - 1); + + return c->table[index].frequency; +} + +static int mtk_cpufreq_hw_cpu_init(struct cpufreq_policy *policy) +{ + struct cpufreq_mtk *c; + + c = mtk_freq_domain_map[policy->cpu]; + if (!c) { + pr_err("No scaling support for CPU%d\n", policy->cpu); + return -ENODEV; + } + + cpumask_copy(policy->cpus, &c->related_cpus); + + policy->freq_table = c->table; + policy->driver_data = c; + + /* HW should be in enabled state to proceed now */ + writel_relaxed(0x1, c->reg_bases[REG_ENABLE]); + + return 0; +} + +static int mtk_cpufreq_hw_cpu_exit(struct cpufreq_policy *policy) +{ + struct cpufreq_mtk *c; + + c = mtk_freq_domain_map[policy->cpu]; + if (!c) { + pr_err("No scaling support for CPU%d\n", policy->cpu); + return -ENODEV; + } + + /* HW should be in paused state now */ + writel_relaxed(0x0, c->reg_bases[REG_ENABLE]); + + return 0; +} + +static struct cpufreq_driver cpufreq_mtk_hw_driver = { + .flags = CPUFREQ_STICKY | CPUFREQ_NEED_INITIAL_FREQ_CHECK | + CPUFREQ_HAVE_GOVERNOR_PER_POLICY, + .verify = cpufreq_generic_frequency_table_verify, + .target_index = mtk_cpufreq_hw_target_index, + .get = mtk_cpufreq_hw_get, + .init = mtk_cpufreq_hw_cpu_init, + .exit = mtk_cpufreq_hw_cpu_exit, + .name = "mtk-cpufreq-hw", + .attr = cpufreq_generic_attr, +}; + +static int mtk_cpu_create_freq_table(struct platform_device *pdev, + struct cpufreq_mtk *c) +{ + struct device *dev = &pdev->dev; + void __iomem *base_table; + u32 data, i, freq, prev_freq = 0; + + c->table = devm_kcalloc(dev, LUT_MAX_ENTRIES + 1, + sizeof(*c->table), GFP_KERNEL); + if (!c->table) + return -ENOMEM; + + base_table = c->reg_bases[REG_LUT_TABLE]; + + for (i = 0; i < LUT_MAX_ENTRIES; i++) { + data = readl_relaxed(base_table + (i * LUT_ROW_SIZE)); + freq = FIELD_GET(LUT_FREQ, data) * 1000; + + if (freq == prev_freq) + break; + + c->table[i].frequency = freq; + + dev_dbg(dev, "index=%d freq=%d\n", + i, c->table[i].frequency); + + prev_freq = freq; + } + + c->table[i].frequency = CPUFREQ_TABLE_END; + + return 0; +} + +static int mtk_get_related_cpus(int index, struct cpufreq_mtk *c) +{ + struct device_node *cpu_np; + struct of_phandle_args args; + int cpu, ret; + + for_each_possible_cpu(cpu) { + cpu_np = of_cpu_device_node_get(cpu); + if (!cpu_np) + continue; + + ret = of_parse_phandle_with_args(cpu_np, "mtk-freq-domain", + "#freq-domain-cells", 0, + &args); + of_node_put(cpu_np); + if (ret < 0) + continue; + + if (index == args.args[0]) { + cpumask_set_cpu(cpu, &c->related_cpus); + mtk_freq_domain_map[cpu] = c; + } + } + + return 0; +} + +static int mtk_cpu_resources_init(struct platform_device *pdev, + unsigned int cpu, int index, + const u16 *offsets) +{ + struct cpufreq_mtk *c; + struct resource *res; + struct device *dev = &pdev->dev; + int ret, i; + void __iomem *base; + + if (mtk_freq_domain_map[cpu]) + return 0; + + c = devm_kzalloc(dev, sizeof(*c), GFP_KERNEL); + if (!c) + return -ENOMEM; + + base = devm_platform_ioremap_resource(pdev, index); + if (IS_ERR(base)) + return PTR_ERR(base); + + for (i = REG_LUT_TABLE; i < REG_ARRAY_SIZE; i++) + c->reg_bases[i] = base + offsets[i]; + + ret = mtk_get_related_cpus(index, c); + if (ret) { + dev_err(dev, "Domain-%d failed to get related CPUs\n", index); + return ret; + } + + ret = mtk_cpu_create_freq_table(pdev, c); + if (ret) { + dev_err(dev, "Domain-%d failed to create freq table\n", index); + return ret; + } + + return 0; +} + +static int mtk_cpufreq_hw_driver_probe(struct platform_device *pdev) +{ + struct device_node *cpu_np; + struct of_phandle_args args; + const u16 *offsets; + unsigned int cpu; + int ret; + + offsets = of_device_get_match_data(&pdev->dev); + if (!offsets) + return -EINVAL; + + for_each_possible_cpu(cpu) { + cpu_np = of_cpu_device_node_get(cpu); + if (!cpu_np) { + dev_err(&pdev->dev, "Failed to get cpu %d device\n", + cpu); + return -ENODEV; + } + + ret = of_parse_phandle_with_args(cpu_np, "mtk-freq-domain", + "#freq-domain-cells", 0, + &args); + if (ret < 0) + return ret; + + /* Get the bases of cpufreq for domains */ + ret = mtk_cpu_resources_init(pdev, cpu, args.args[0], offsets); + if (ret) { + dev_err(&pdev->dev, "CPUFreq resource init failed\n"); + return ret; + } + } + + ret = cpufreq_register_driver(&cpufreq_mtk_hw_driver); + if (ret) { + dev_err(&pdev->dev, "CPUFreq HW driver failed to register\n"); + return ret; + } + + return 0; +} + +static int mtk_cpufreq_hw_driver_remove(struct platform_device *pdev) +{ + return cpufreq_unregister_driver(&cpufreq_mtk_hw_driver); +} + +static const struct of_device_id mtk_cpufreq_hw_match[] = { + { .compatible = "mediatek,cpufreq-hw", .data = &cpufreq_mtk_offsets }, + {} +}; + +static struct platform_driver mtk_cpufreq_hw_driver = { + .probe = mtk_cpufreq_hw_driver_probe, + .remove = mtk_cpufreq_hw_driver_remove, + .driver = { + .name = "mtk-cpufreq-hw", + .of_match_table = mtk_cpufreq_hw_match, + }, +}; +module_platform_driver(mtk_cpufreq_hw_driver); + +MODULE_DESCRIPTION("Mediatek cpufreq-hw driver"); +MODULE_LICENSE("GPL v2"); -- 1.7.9.5 ^ permalink raw reply related [flat|nested] 16+ messages in thread
* [PATCH v7 2/2] dt-bindings: cpufreq: add bindings for MediaTek cpufreq HW 2020-09-10 4:31 [PATCH v7] cpufreq: mediatek-hw: Add support for Mediatek cpufreq HW driver Hector Yuan 2020-09-10 4:31 ` [PATCH v7 1/2] " Hector Yuan @ 2020-09-10 4:31 ` Hector Yuan 2020-09-21 2:23 ` Hector Yuan 2020-09-22 20:28 ` Rob Herring 2020-09-10 5:03 ` [PATCH v7] cpufreq: mediatek-hw: Add support for Mediatek cpufreq HW driver Viresh Kumar 2 siblings, 2 replies; 16+ messages in thread From: Hector Yuan @ 2020-09-10 4:31 UTC (permalink / raw) To: linux-mediatek, linux-arm-kernel, linux-pm, devicetree, Rafael J. Wysocki, Viresh Kumar, Rob Herring Cc: linux-kernel, wsd_upstream, hector.yuan From: "Hector.Yuan" <hector.yuan@mediatek.com> Add devicetree bindings for MediaTek HW driver. Signed-off-by: Hector.Yuan <hector.yuan@mediatek.com> --- .../bindings/cpufreq/cpufreq-mediatek-hw.yaml | 141 ++++++++++++++++++++ 1 file changed, 141 insertions(+) create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml new file mode 100644 index 0000000..118a163 --- /dev/null +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml @@ -0,0 +1,141 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/cpufreq/cpufreq-mediatek-hw.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MediaTek's CPUFREQ Bindings + +maintainers: + - Hector Yuan <hector.yuan@mediatek.com> + +description: + CPUFREQ HW is a hardware engine used by MediaTek + SoCs to manage frequency in hardware. It is capable of controlling frequency + for multiple clusters. + +properties: + compatible: + const: "mediatek,cpufreq-hw" + + reg: + minItems: 1 + maxItems: 2 + description: | + Addresses and sizes for the memory of the HW bases in each frequency domain. + + reg-names: + items: + - const: "freq-domain0" + - const: "freq-domain1" + description: | + Frequency domain name. i.e. + "freq-domain0", "freq-domain1". + + "#freq-domain-cells": + const: 1 + description: | + Number of cells in a freqency domain specifier. + + mtk-freq-domain: + maxItems: 1 + description: | + Define this cpu belongs to which frequency domain. i.e. + cpu0-3 belong to frequency domain0, + cpu4-6 belong to frequency domain1. + +required: + - compatible + - reg + - reg-names + - "#freq-domain-cells" + +examples: + - | + cpus { + #address-cells = <1>; + #size-cells = <0>; + + cpu0: cpu@0 { + device_type = "cpu"; + compatible = "arm,cortex-a55"; + enable-method = "psci"; + mtk-freq-domain = <&cpufreq_hw 0>; + reg = <0x000>; + }; + + cpu1: cpu@1 { + device_type = "cpu"; + compatible = "arm,cortex-a55"; + enable-method = "psci"; + mtk-freq-domain = <&cpufreq_hw 0>; + reg = <0x100>; + }; + + cpu2: cpu@2 { + device_type = "cpu"; + compatible = "arm,cortex-a55"; + enable-method = "psci"; + mtk-freq-domain = <&cpufreq_hw 0>; + reg = <0x200>; + }; + + cpu3: cpu@3 { + device_type = "cpu"; + compatible = "arm,cortex-a55"; + enable-method = "psci"; + mtk-freq-domain = <&cpufreq_hw 0>; + reg = <0x300>; + }; + + cpu4: cpu@4 { + device_type = "cpu"; + compatible = "arm,cortex-a55"; + enable-method = "psci"; + mtk-freq-domain = <&cpufreq_hw 1>; + reg = <0x400>; + }; + + cpu5: cpu@5 { + device_type = "cpu"; + compatible = "arm,cortex-a55"; + enable-method = "psci"; + mtk-freq-domain = <&cpufreq_hw 1>; + reg = <0x500>; + }; + + cpu6: cpu@6 { + device_type = "cpu"; + compatible = "arm,cortex-a75"; + enable-method = "psci"; + mtk-freq-domain = <&cpufreq_hw 1>; + reg = <0x600>; + }; + + cpu7: cpu@7 { + device_type = "cpu"; + compatible = "arm,cortex-a75"; + enable-method = "psci"; + mtk-freq-domain = <&cpufreq_hw 1>; + reg = <0x700>; + }; + }; + + /* ... */ + + soc { + #address-cells = <2>; + #size-cells = <2>; + + cpufreq_hw: cpufreq@11bc00 { + compatible = "mediatek,cpufreq-hw"; + reg = <0 0x11bc10 0 0x8c>, + <0 0x11bca0 0 0x8c>; + reg-names = "freq-domain0", "freq-domain1"; + #freq-domain-cells = <1>; + }; + }; + + + + -- 1.7.9.5 ^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: [PATCH v7 2/2] dt-bindings: cpufreq: add bindings for MediaTek cpufreq HW 2020-09-10 4:31 ` [PATCH v7 2/2] dt-bindings: cpufreq: add bindings for MediaTek cpufreq HW Hector Yuan @ 2020-09-21 2:23 ` Hector Yuan 2020-09-22 20:28 ` Rob Herring 1 sibling, 0 replies; 16+ messages in thread From: Hector Yuan @ 2020-09-21 2:23 UTC (permalink / raw) To: Rob Herring Cc: linux-arm-kernel, linux-pm, devicetree, Rafael J. Wysocki, Viresh Kumar, linux-mediatek, linux-kernel, wsd_upstream Hi, Rob sir: Sorry to bother you, may I have your review comment for the binding part? Appreciated. On Thu, 2020-09-10 at 12:31 +0800, Hector Yuan wrote: > From: "Hector.Yuan" <hector.yuan@mediatek.com> > > Add devicetree bindings for MediaTek HW driver. > > Signed-off-by: Hector.Yuan <hector.yuan@mediatek.com> > --- > .../bindings/cpufreq/cpufreq-mediatek-hw.yaml | 141 ++++++++++++++++++++ > 1 file changed, 141 insertions(+) > create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml > > diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml > new file mode 100644 > index 0000000..118a163 > --- /dev/null > +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml > @@ -0,0 +1,141 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/cpufreq/cpufreq-mediatek-hw.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: MediaTek's CPUFREQ Bindings > + > +maintainers: > + - Hector Yuan <hector.yuan@mediatek.com> > + > +description: > + CPUFREQ HW is a hardware engine used by MediaTek > + SoCs to manage frequency in hardware. It is capable of controlling frequency > + for multiple clusters. > + > +properties: > + compatible: > + const: "mediatek,cpufreq-hw" > + > + reg: > + minItems: 1 > + maxItems: 2 > + description: | > + Addresses and sizes for the memory of the HW bases in each frequency domain. > + > + reg-names: > + items: > + - const: "freq-domain0" > + - const: "freq-domain1" > + description: | > + Frequency domain name. i.e. > + "freq-domain0", "freq-domain1". > + > + "#freq-domain-cells": > + const: 1 > + description: | > + Number of cells in a freqency domain specifier. > + > + mtk-freq-domain: > + maxItems: 1 > + description: | > + Define this cpu belongs to which frequency domain. i.e. > + cpu0-3 belong to frequency domain0, > + cpu4-6 belong to frequency domain1. > + > +required: > + - compatible > + - reg > + - reg-names > + - "#freq-domain-cells" > + > +examples: > + - | > + cpus { > + #address-cells = <1>; > + #size-cells = <0>; > + > + cpu0: cpu@0 { > + device_type = "cpu"; > + compatible = "arm,cortex-a55"; > + enable-method = "psci"; > + mtk-freq-domain = <&cpufreq_hw 0>; > + reg = <0x000>; > + }; > + > + cpu1: cpu@1 { > + device_type = "cpu"; > + compatible = "arm,cortex-a55"; > + enable-method = "psci"; > + mtk-freq-domain = <&cpufreq_hw 0>; > + reg = <0x100>; > + }; > + > + cpu2: cpu@2 { > + device_type = "cpu"; > + compatible = "arm,cortex-a55"; > + enable-method = "psci"; > + mtk-freq-domain = <&cpufreq_hw 0>; > + reg = <0x200>; > + }; > + > + cpu3: cpu@3 { > + device_type = "cpu"; > + compatible = "arm,cortex-a55"; > + enable-method = "psci"; > + mtk-freq-domain = <&cpufreq_hw 0>; > + reg = <0x300>; > + }; > + > + cpu4: cpu@4 { > + device_type = "cpu"; > + compatible = "arm,cortex-a55"; > + enable-method = "psci"; > + mtk-freq-domain = <&cpufreq_hw 1>; > + reg = <0x400>; > + }; > + > + cpu5: cpu@5 { > + device_type = "cpu"; > + compatible = "arm,cortex-a55"; > + enable-method = "psci"; > + mtk-freq-domain = <&cpufreq_hw 1>; > + reg = <0x500>; > + }; > + > + cpu6: cpu@6 { > + device_type = "cpu"; > + compatible = "arm,cortex-a75"; > + enable-method = "psci"; > + mtk-freq-domain = <&cpufreq_hw 1>; > + reg = <0x600>; > + }; > + > + cpu7: cpu@7 { > + device_type = "cpu"; > + compatible = "arm,cortex-a75"; > + enable-method = "psci"; > + mtk-freq-domain = <&cpufreq_hw 1>; > + reg = <0x700>; > + }; > + }; > + > + /* ... */ > + > + soc { > + #address-cells = <2>; > + #size-cells = <2>; > + > + cpufreq_hw: cpufreq@11bc00 { > + compatible = "mediatek,cpufreq-hw"; > + reg = <0 0x11bc10 0 0x8c>, > + <0 0x11bca0 0 0x8c>; > + reg-names = "freq-domain0", "freq-domain1"; > + #freq-domain-cells = <1>; > + }; > + }; > + > + > + > + ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v7 2/2] dt-bindings: cpufreq: add bindings for MediaTek cpufreq HW 2020-09-10 4:31 ` [PATCH v7 2/2] dt-bindings: cpufreq: add bindings for MediaTek cpufreq HW Hector Yuan 2020-09-21 2:23 ` Hector Yuan @ 2020-09-22 20:28 ` Rob Herring 2020-09-23 13:10 ` Hector Yuan 1 sibling, 1 reply; 16+ messages in thread From: Rob Herring @ 2020-09-22 20:28 UTC (permalink / raw) To: Hector Yuan Cc: linux-mediatek, linux-arm-kernel, linux-pm, devicetree, Rafael J. Wysocki, Viresh Kumar, linux-kernel, wsd_upstream On Thu, Sep 10, 2020 at 12:31:02PM +0800, Hector Yuan wrote: > From: "Hector.Yuan" <hector.yuan@mediatek.com> > > Add devicetree bindings for MediaTek HW driver. > > Signed-off-by: Hector.Yuan <hector.yuan@mediatek.com> > --- > .../bindings/cpufreq/cpufreq-mediatek-hw.yaml | 141 ++++++++++++++++++++ > 1 file changed, 141 insertions(+) > create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml > > diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml > new file mode 100644 > index 0000000..118a163 > --- /dev/null > +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml > @@ -0,0 +1,141 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/cpufreq/cpufreq-mediatek-hw.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: MediaTek's CPUFREQ Bindings > + > +maintainers: > + - Hector Yuan <hector.yuan@mediatek.com> > + > +description: > + CPUFREQ HW is a hardware engine used by MediaTek > + SoCs to manage frequency in hardware. It is capable of controlling frequency > + for multiple clusters. > + > +properties: > + compatible: > + const: "mediatek,cpufreq-hw" Needs to be SoC specific. This stuff is never constant from one SoC to the next. 'cpufreq' is a Linuxism. What's the block called in the datasheet? Use that. Don't need quotes either. > + > + reg: > + minItems: 1 > + maxItems: 2 > + description: | > + Addresses and sizes for the memory of the HW bases in each frequency domain. > + > + reg-names: > + items: > + - const: "freq-domain0" > + - const: "freq-domain1" Kind of pointless to have names based on the index. Drop 'reg-names'. > + description: | > + Frequency domain name. i.e. > + "freq-domain0", "freq-domain1". > + > + "#freq-domain-cells": > + const: 1 > + description: | > + Number of cells in a freqency domain specifier. You don't need this. It's not a common binding that's going to vary. > + > + mtk-freq-domain: > + maxItems: 1 > + description: | > + Define this cpu belongs to which frequency domain. i.e. > + cpu0-3 belong to frequency domain0, > + cpu4-6 belong to frequency domain1. This property doesn't go in the 'mediatek,cpufreq-hw' node. You would need a separate schema. However, I think the easiest thing to do here is something like this: mediatek,freq-domain-0 = <&cpu0>, <&cpu1>; Or you could just re-use the OPP binding with just 0 entries: opp-table-0 { compatible = "mediatek,hw-operating-points", "operating-points-v2"; }; opp-table-1 { compatible = "mediatek,hw-operating-points", "operating-points-v2"; }; > + > +required: > + - compatible > + - reg > + - reg-names > + - "#freq-domain-cells" > + > +examples: > + - | > + cpus { > + #address-cells = <1>; > + #size-cells = <0>; > + > + cpu0: cpu@0 { > + device_type = "cpu"; > + compatible = "arm,cortex-a55"; > + enable-method = "psci"; > + mtk-freq-domain = <&cpufreq_hw 0>; > + reg = <0x000>; > + }; > + > + cpu1: cpu@1 { Unit address is wrong. > + device_type = "cpu"; > + compatible = "arm,cortex-a55"; > + enable-method = "psci"; > + mtk-freq-domain = <&cpufreq_hw 0>; > + reg = <0x100>; > + }; > + > + cpu2: cpu@2 { > + device_type = "cpu"; > + compatible = "arm,cortex-a55"; > + enable-method = "psci"; > + mtk-freq-domain = <&cpufreq_hw 0>; > + reg = <0x200>; > + }; > + > + cpu3: cpu@3 { > + device_type = "cpu"; > + compatible = "arm,cortex-a55"; > + enable-method = "psci"; > + mtk-freq-domain = <&cpufreq_hw 0>; > + reg = <0x300>; > + }; > + > + cpu4: cpu@4 { > + device_type = "cpu"; > + compatible = "arm,cortex-a55"; > + enable-method = "psci"; > + mtk-freq-domain = <&cpufreq_hw 1>; > + reg = <0x400>; > + }; > + > + cpu5: cpu@5 { > + device_type = "cpu"; > + compatible = "arm,cortex-a55"; > + enable-method = "psci"; > + mtk-freq-domain = <&cpufreq_hw 1>; > + reg = <0x500>; > + }; > + > + cpu6: cpu@6 { > + device_type = "cpu"; > + compatible = "arm,cortex-a75"; > + enable-method = "psci"; > + mtk-freq-domain = <&cpufreq_hw 1>; > + reg = <0x600>; > + }; > + > + cpu7: cpu@7 { > + device_type = "cpu"; > + compatible = "arm,cortex-a75"; > + enable-method = "psci"; > + mtk-freq-domain = <&cpufreq_hw 1>; > + reg = <0x700>; > + }; > + }; > + > + /* ... */ > + > + soc { > + #address-cells = <2>; > + #size-cells = <2>; > + > + cpufreq_hw: cpufreq@11bc00 { > + compatible = "mediatek,cpufreq-hw"; > + reg = <0 0x11bc10 0 0x8c>, > + <0 0x11bca0 0 0x8c>; > + reg-names = "freq-domain0", "freq-domain1"; > + #freq-domain-cells = <1>; > + }; > + }; > + > + > + > + > -- > 1.7.9.5 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v7 2/2] dt-bindings: cpufreq: add bindings for MediaTek cpufreq HW 2020-09-22 20:28 ` Rob Herring @ 2020-09-23 13:10 ` Hector Yuan 2020-09-24 2:36 ` Hector Yuan 2020-09-25 2:27 ` Hector Yuan 0 siblings, 2 replies; 16+ messages in thread From: Hector Yuan @ 2020-09-23 13:10 UTC (permalink / raw) To: Rob Herring Cc: linux-mediatek, linux-arm-kernel, linux-pm, devicetree, Rafael J. Wysocki, Viresh Kumar, linux-kernel, wsd_upstream On Tue, 2020-09-22 at 14:28 -0600, Rob Herring wrote: > On Thu, Sep 10, 2020 at 12:31:02PM +0800, Hector Yuan wrote: > > From: "Hector.Yuan" <hector.yuan@mediatek.com> > > > > Add devicetree bindings for MediaTek HW driver. > > > > Signed-off-by: Hector.Yuan <hector.yuan@mediatek.com> > > --- > > .../bindings/cpufreq/cpufreq-mediatek-hw.yaml | 141 ++++++++++++++++++++ > > 1 file changed, 141 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml > > > > diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml > > new file mode 100644 > > index 0000000..118a163 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml > > @@ -0,0 +1,141 @@ > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/cpufreq/cpufreq-mediatek-hw.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: MediaTek's CPUFREQ Bindings > > + > > +maintainers: > > + - Hector Yuan <hector.yuan@mediatek.com> > > + > > +description: > > + CPUFREQ HW is a hardware engine used by MediaTek > > + SoCs to manage frequency in hardware. It is capable of controlling frequency > > + for multiple clusters. > > + > > +properties: > > + compatible: > > + const: "mediatek,cpufreq-hw" > > Needs to be SoC specific. This stuff is never constant from one SoC to > the next. 'cpufreq' is a Linuxism. What's the block called in the > datasheet? Use that. > OK, will use mediatek,sspm-dvfs-mt6779 instead. > Don't need quotes either. > OK, will remove it. > > + > > + reg: > > + minItems: 1 > > + maxItems: 2 > > + description: | > > + Addresses and sizes for the memory of the HW bases in each frequency domain. > > + > > + reg-names: > > + items: > > + - const: "freq-domain0" > > + - const: "freq-domain1" > > Kind of pointless to have names based on the index. Drop 'reg-names'. > OK, will drop it. > > + description: | > > + Frequency domain name. i.e. > > + "freq-domain0", "freq-domain1". > > + > > + "#freq-domain-cells": > > + const: 1 > > + description: | > > + Number of cells in a freqency domain specifier. > > You don't need this. It's not a common binding that's going to vary. > OK, will remove it. > > + > > + mtk-freq-domain: > > + maxItems: 1 > > + description: | > > + Define this cpu belongs to which frequency domain. i.e. > > + cpu0-3 belong to frequency domain0, > > + cpu4-6 belong to frequency domain1. > > This property doesn't go in the 'mediatek,cpufreq-hw' node. You would > need a separate schema. However, I think the easiest thing to do here is > something like this: > > mediatek,freq-domain-0 = <&cpu0>, <&cpu1>; > Sorry, may I know the reason and the details about how to separate schema? Thank you very much. The numbers of frequency domain may be vary from different projects. If I do the easier way, I may need to implement extra loop to check how many frequency domain. > Or you could just re-use the OPP binding with just 0 entries: > > opp-table-0 { > compatible = "mediatek,hw-operating-points", "operating-points-v2"; > }; > opp-table-1 { > compatible = "mediatek,hw-operating-points", "operating-points-v2"; > }; > In previous review stage, already abandon OPP framework in driver code. Will check with Viresh to see if its OK to add OPP back. > > + > > +required: > > + - compatible > > + - reg > > + - reg-names > > + - "#freq-domain-cells" > > + > > +examples: > > + - | > > + cpus { > > + #address-cells = <1>; > > + #size-cells = <0>; > > + > > + cpu0: cpu@0 { > > + device_type = "cpu"; > > + compatible = "arm,cortex-a55"; > > + enable-method = "psci"; > > + mtk-freq-domain = <&cpufreq_hw 0>; > > + reg = <0x000>; > > + }; > > + > > + cpu1: cpu@1 { > > Unit address is wrong. > OK, will modify to "cpu1 : cpu@100" if we still decide to put freq_domain in CPU node. > > + device_type = "cpu"; > > + compatible = "arm,cortex-a55"; > > + enable-method = "psci"; > > + mtk-freq-domain = <&cpufreq_hw 0>; > > + reg = <0x100>; > > + }; > > + > > + cpu2: cpu@2 { > > + device_type = "cpu"; > > + compatible = "arm,cortex-a55"; > > + enable-method = "psci"; > > + mtk-freq-domain = <&cpufreq_hw 0>; > > + reg = <0x200>; > > + }; > > + > > + cpu3: cpu@3 { > > + device_type = "cpu"; > > + compatible = "arm,cortex-a55"; > > + enable-method = "psci"; > > + mtk-freq-domain = <&cpufreq_hw 0>; > > + reg = <0x300>; > > + }; > > + > > + cpu4: cpu@4 { > > + device_type = "cpu"; > > + compatible = "arm,cortex-a55"; > > + enable-method = "psci"; > > + mtk-freq-domain = <&cpufreq_hw 1>; > > + reg = <0x400>; > > + }; > > + > > + cpu5: cpu@5 { > > + device_type = "cpu"; > > + compatible = "arm,cortex-a55"; > > + enable-method = "psci"; > > + mtk-freq-domain = <&cpufreq_hw 1>; > > + reg = <0x500>; > > + }; > > + > > + cpu6: cpu@6 { > > + device_type = "cpu"; > > + compatible = "arm,cortex-a75"; > > + enable-method = "psci"; > > + mtk-freq-domain = <&cpufreq_hw 1>; > > + reg = <0x600>; > > + }; > > + > > + cpu7: cpu@7 { > > + device_type = "cpu"; > > + compatible = "arm,cortex-a75"; > > + enable-method = "psci"; > > + mtk-freq-domain = <&cpufreq_hw 1>; > > + reg = <0x700>; > > + }; > > + }; > > + > > + /* ... */ > > + > > + soc { > > + #address-cells = <2>; > > + #size-cells = <2>; > > + > > + cpufreq_hw: cpufreq@11bc00 { > > + compatible = "mediatek,cpufreq-hw"; > > + reg = <0 0x11bc10 0 0x8c>, > > + <0 0x11bca0 0 0x8c>; > > + reg-names = "freq-domain0", "freq-domain1"; > > + #freq-domain-cells = <1>; > > + }; > > + }; > > + > > + > > + > > + > > -- > > 1.7.9.5 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v7 2/2] dt-bindings: cpufreq: add bindings for MediaTek cpufreq HW 2020-09-23 13:10 ` Hector Yuan @ 2020-09-24 2:36 ` Hector Yuan 2020-09-25 2:27 ` Hector Yuan 1 sibling, 0 replies; 16+ messages in thread From: Hector Yuan @ 2020-09-24 2:36 UTC (permalink / raw) To: Rob Herring Cc: linux-mediatek, linux-arm-kernel, linux-pm, devicetree, Rafael J. Wysocki, Viresh Kumar, linux-kernel, wsd_upstream On Wed, 2020-09-23 at 21:10 +0800, Hector Yuan wrote: > On Tue, 2020-09-22 at 14:28 -0600, Rob Herring wrote: > > On Thu, Sep 10, 2020 at 12:31:02PM +0800, Hector Yuan wrote: > > > From: "Hector.Yuan" <hector.yuan@mediatek.com> > > > > > > Add devicetree bindings for MediaTek HW driver. > > > > > > Signed-off-by: Hector.Yuan <hector.yuan@mediatek.com> > > > --- > > > .../bindings/cpufreq/cpufreq-mediatek-hw.yaml | 141 ++++++++++++++++++++ > > > 1 file changed, 141 insertions(+) > > > create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml > > > > > > diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml > > > new file mode 100644 > > > index 0000000..118a163 > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml > > > @@ -0,0 +1,141 @@ > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > +%YAML 1.2 > > > +--- > > > +$id: http://devicetree.org/schemas/cpufreq/cpufreq-mediatek-hw.yaml# > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > + > > > +title: MediaTek's CPUFREQ Bindings > > > + > > > +maintainers: > > > + - Hector Yuan <hector.yuan@mediatek.com> > > > + > > > +description: > > > + CPUFREQ HW is a hardware engine used by MediaTek > > > + SoCs to manage frequency in hardware. It is capable of controlling frequency > > > + for multiple clusters. > > > + > > > +properties: > > > + compatible: > > > + const: "mediatek,cpufreq-hw" > > > > Needs to be SoC specific. This stuff is never constant from one SoC to > > the next. 'cpufreq' is a Linuxism. What's the block called in the > > datasheet? Use that. > > > OK, will use mediatek,sspm-dvfs-mt6779 instead. > > Don't need quotes either. > > > OK, will remove it. > > > + > > > + reg: > > > + minItems: 1 > > > + maxItems: 2 > > > + description: | > > > + Addresses and sizes for the memory of the HW bases in each frequency domain. > > > + > > > + reg-names: > > > + items: > > > + - const: "freq-domain0" > > > + - const: "freq-domain1" > > > > Kind of pointless to have names based on the index. Drop 'reg-names'. > > > OK, will drop it. > > > + description: | > > > + Frequency domain name. i.e. > > > + "freq-domain0", "freq-domain1". > > > + > > > + "#freq-domain-cells": > > > + const: 1 > > > + description: | > > > + Number of cells in a freqency domain specifier. > > > > You don't need this. It's not a common binding that's going to vary. > > > OK, will remove it. > > > + > > > + mtk-freq-domain: > > > + maxItems: 1 > > > + description: | > > > + Define this cpu belongs to which frequency domain. i.e. > > > + cpu0-3 belong to frequency domain0, > > > + cpu4-6 belong to frequency domain1. > > > > This property doesn't go in the 'mediatek,cpufreq-hw' node. You would > > need a separate schema. However, I think the easiest thing to do here is > > something like this: > > > > mediatek,freq-domain-0 = <&cpu0>, <&cpu1>; > > > Sorry, may I know the reason and the details about how to separate > schema? Thank you very much. > Actually, I referenced the thermal-cooling-devices and send my yaml for review. https://elixir.bootlin.com/linux/v5.9-rc6/source/Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml It used cpu node for cooling device, and thermal schema use it. Appreciated for any details. > The numbers of frequency domain may be vary from different projects. If > I do the easier way, I may need to implement extra loop to check how > many frequency domain. > > Or you could just re-use the OPP binding with just 0 entries: > > > > opp-table-0 { > > compatible = "mediatek,hw-operating-points", "operating-points-v2"; > > }; > > opp-table-1 { > > compatible = "mediatek,hw-operating-points", "operating-points-v2"; > > }; > > > In previous review stage, already abandon OPP framework in driver code. > Will check with Viresh to see if its OK to add OPP back. > > > + > > > +required: > > > + - compatible > > > + - reg > > > + - reg-names > > > + - "#freq-domain-cells" > > > + > > > +examples: > > > + - | > > > + cpus { > > > + #address-cells = <1>; > > > + #size-cells = <0>; > > > + > > > + cpu0: cpu@0 { > > > + device_type = "cpu"; > > > + compatible = "arm,cortex-a55"; > > > + enable-method = "psci"; > > > + mtk-freq-domain = <&cpufreq_hw 0>; > > > + reg = <0x000>; > > > + }; > > > + > > > + cpu1: cpu@1 { > > > > Unit address is wrong. > > > OK, will modify to "cpu1 : cpu@100" if we still decide to put > freq_domain in CPU node. > > > + device_type = "cpu"; > > > + compatible = "arm,cortex-a55"; > > > + enable-method = "psci"; > > > + mtk-freq-domain = <&cpufreq_hw 0>; > > > + reg = <0x100>; > > > + }; > > > + > > > + cpu2: cpu@2 { > > > + device_type = "cpu"; > > > + compatible = "arm,cortex-a55"; > > > + enable-method = "psci"; > > > + mtk-freq-domain = <&cpufreq_hw 0>; > > > + reg = <0x200>; > > > + }; > > > + > > > + cpu3: cpu@3 { > > > + device_type = "cpu"; > > > + compatible = "arm,cortex-a55"; > > > + enable-method = "psci"; > > > + mtk-freq-domain = <&cpufreq_hw 0>; > > > + reg = <0x300>; > > > + }; > > > + > > > + cpu4: cpu@4 { > > > + device_type = "cpu"; > > > + compatible = "arm,cortex-a55"; > > > + enable-method = "psci"; > > > + mtk-freq-domain = <&cpufreq_hw 1>; > > > + reg = <0x400>; > > > + }; > > > + > > > + cpu5: cpu@5 { > > > + device_type = "cpu"; > > > + compatible = "arm,cortex-a55"; > > > + enable-method = "psci"; > > > + mtk-freq-domain = <&cpufreq_hw 1>; > > > + reg = <0x500>; > > > + }; > > > + > > > + cpu6: cpu@6 { > > > + device_type = "cpu"; > > > + compatible = "arm,cortex-a75"; > > > + enable-method = "psci"; > > > + mtk-freq-domain = <&cpufreq_hw 1>; > > > + reg = <0x600>; > > > + }; > > > + > > > + cpu7: cpu@7 { > > > + device_type = "cpu"; > > > + compatible = "arm,cortex-a75"; > > > + enable-method = "psci"; > > > + mtk-freq-domain = <&cpufreq_hw 1>; > > > + reg = <0x700>; > > > + }; > > > + }; > > > + > > > + /* ... */ > > > + > > > + soc { > > > + #address-cells = <2>; > > > + #size-cells = <2>; > > > + > > > + cpufreq_hw: cpufreq@11bc00 { > > > + compatible = "mediatek,cpufreq-hw"; > > > + reg = <0 0x11bc10 0 0x8c>, > > > + <0 0x11bca0 0 0x8c>; > > > + reg-names = "freq-domain0", "freq-domain1"; > > > + #freq-domain-cells = <1>; > > > + }; > > > + }; > > > + > > > + > > > + > > > + > > > -- > > > 1.7.9.5 > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v7 2/2] dt-bindings: cpufreq: add bindings for MediaTek cpufreq HW 2020-09-23 13:10 ` Hector Yuan 2020-09-24 2:36 ` Hector Yuan @ 2020-09-25 2:27 ` Hector Yuan 2020-09-25 6:15 ` Viresh Kumar 1 sibling, 1 reply; 16+ messages in thread From: Hector Yuan @ 2020-09-25 2:27 UTC (permalink / raw) To: Rob Herring, Viresh Kumar Cc: linux-mediatek, linux-arm-kernel, linux-pm, devicetree, Rafael J. Wysocki, Viresh Kumar, linux-kernel, wsd_upstream Hi, Viresh & Rob Sir: I will change frequency domain to below and define it in cpufreq_hw schema rather than cpu node. mediatek,freq-domain-0 = <&cpu0>, <&cpu1>; Is it OK to you? Or you think OPP define is a better solution? opp-table-0 { compatible = "mediatek,hw-operating-points", "operating-points-v2"; }; Thank you for the opinions. On Wed, 2020-09-23 at 21:10 +0800, Hector Yuan wrote: > On Tue, 2020-09-22 at 14:28 -0600, Rob Herring wrote: > > On Thu, Sep 10, 2020 at 12:31:02PM +0800, Hector Yuan wrote: > > > From: "Hector.Yuan" <hector.yuan@mediatek.com> > > > > > > Add devicetree bindings for MediaTek HW driver. > > > > > > Signed-off-by: Hector.Yuan <hector.yuan@mediatek.com> > > > --- > > > .../bindings/cpufreq/cpufreq-mediatek-hw.yaml | 141 ++++++++++++++++++++ > > > 1 file changed, 141 insertions(+) > > > create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml > > > > > > diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml > > > new file mode 100644 > > > index 0000000..118a163 > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml > > > @@ -0,0 +1,141 @@ > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > +%YAML 1.2 > > > +--- > > > +$id: http://devicetree.org/schemas/cpufreq/cpufreq-mediatek-hw.yaml# > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > + > > > +title: MediaTek's CPUFREQ Bindings > > > + > > > +maintainers: > > > + - Hector Yuan <hector.yuan@mediatek.com> > > > + > > > +description: > > > + CPUFREQ HW is a hardware engine used by MediaTek > > > + SoCs to manage frequency in hardware. It is capable of controlling frequency > > > + for multiple clusters. > > > + > > > +properties: > > > + compatible: > > > + const: "mediatek,cpufreq-hw" > > > > Needs to be SoC specific. This stuff is never constant from one SoC to > > the next. 'cpufreq' is a Linuxism. What's the block called in the > > datasheet? Use that. > > > OK, will use mediatek,sspm-dvfs-mt6779 instead. > > Don't need quotes either. > > > OK, will remove it. > > > + > > > + reg: > > > + minItems: 1 > > > + maxItems: 2 > > > + description: | > > > + Addresses and sizes for the memory of the HW bases in each frequency domain. > > > + > > > + reg-names: > > > + items: > > > + - const: "freq-domain0" > > > + - const: "freq-domain1" > > > > Kind of pointless to have names based on the index. Drop 'reg-names'. > > > OK, will drop it. > > > + description: | > > > + Frequency domain name. i.e. > > > + "freq-domain0", "freq-domain1". > > > + > > > + "#freq-domain-cells": > > > + const: 1 > > > + description: | > > > + Number of cells in a freqency domain specifier. > > > > You don't need this. It's not a common binding that's going to vary. > > > OK, will remove it. > > > + > > > + mtk-freq-domain: > > > + maxItems: 1 > > > + description: | > > > + Define this cpu belongs to which frequency domain. i.e. > > > + cpu0-3 belong to frequency domain0, > > > + cpu4-6 belong to frequency domain1. > > > > This property doesn't go in the 'mediatek,cpufreq-hw' node. You would > > need a separate schema. However, I think the easiest thing to do here is > > something like this: > > > > mediatek,freq-domain-0 = <&cpu0>, <&cpu1>; > > > Sorry, may I know the reason and the details about how to separate > schema? Thank you very much. > > The numbers of frequency domain may be vary from different projects. If > I do the easier way, I may need to implement extra loop to check how > many frequency domain. > > Or you could just re-use the OPP binding with just 0 entries: > > > > opp-table-0 { > > compatible = "mediatek,hw-operating-points", "operating-points-v2"; > > }; > > opp-table-1 { > > compatible = "mediatek,hw-operating-points", "operating-points-v2"; > > }; > > > In previous review stage, already abandon OPP framework in driver code. > Will check with Viresh to see if its OK to add OPP back. > > > + > > > +required: > > > + - compatible > > > + - reg > > > + - reg-names > > > + - "#freq-domain-cells" > > > + > > > +examples: > > > + - | > > > + cpus { > > > + #address-cells = <1>; > > > + #size-cells = <0>; > > > + > > > + cpu0: cpu@0 { > > > + device_type = "cpu"; > > > + compatible = "arm,cortex-a55"; > > > + enable-method = "psci"; > > > + mtk-freq-domain = <&cpufreq_hw 0>; > > > + reg = <0x000>; > > > + }; > > > + > > > + cpu1: cpu@1 { > > > > Unit address is wrong. > > > OK, will modify to "cpu1 : cpu@100" if we still decide to put > freq_domain in CPU node. > > > + device_type = "cpu"; > > > + compatible = "arm,cortex-a55"; > > > + enable-method = "psci"; > > > + mtk-freq-domain = <&cpufreq_hw 0>; > > > + reg = <0x100>; > > > + }; > > > + > > > + cpu2: cpu@2 { > > > + device_type = "cpu"; > > > + compatible = "arm,cortex-a55"; > > > + enable-method = "psci"; > > > + mtk-freq-domain = <&cpufreq_hw 0>; > > > + reg = <0x200>; > > > + }; > > > + > > > + cpu3: cpu@3 { > > > + device_type = "cpu"; > > > + compatible = "arm,cortex-a55"; > > > + enable-method = "psci"; > > > + mtk-freq-domain = <&cpufreq_hw 0>; > > > + reg = <0x300>; > > > + }; > > > + > > > + cpu4: cpu@4 { > > > + device_type = "cpu"; > > > + compatible = "arm,cortex-a55"; > > > + enable-method = "psci"; > > > + mtk-freq-domain = <&cpufreq_hw 1>; > > > + reg = <0x400>; > > > + }; > > > + > > > + cpu5: cpu@5 { > > > + device_type = "cpu"; > > > + compatible = "arm,cortex-a55"; > > > + enable-method = "psci"; > > > + mtk-freq-domain = <&cpufreq_hw 1>; > > > + reg = <0x500>; > > > + }; > > > + > > > + cpu6: cpu@6 { > > > + device_type = "cpu"; > > > + compatible = "arm,cortex-a75"; > > > + enable-method = "psci"; > > > + mtk-freq-domain = <&cpufreq_hw 1>; > > > + reg = <0x600>; > > > + }; > > > + > > > + cpu7: cpu@7 { > > > + device_type = "cpu"; > > > + compatible = "arm,cortex-a75"; > > > + enable-method = "psci"; > > > + mtk-freq-domain = <&cpufreq_hw 1>; > > > + reg = <0x700>; > > > + }; > > > + }; > > > + > > > + /* ... */ > > > + > > > + soc { > > > + #address-cells = <2>; > > > + #size-cells = <2>; > > > + > > > + cpufreq_hw: cpufreq@11bc00 { > > > + compatible = "mediatek,cpufreq-hw"; > > > + reg = <0 0x11bc10 0 0x8c>, > > > + <0 0x11bca0 0 0x8c>; > > > + reg-names = "freq-domain0", "freq-domain1"; > > > + #freq-domain-cells = <1>; > > > + }; > > > + }; > > > + > > > + > > > + > > > + > > > -- > > > 1.7.9.5 > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v7 2/2] dt-bindings: cpufreq: add bindings for MediaTek cpufreq HW 2020-09-25 2:27 ` Hector Yuan @ 2020-09-25 6:15 ` Viresh Kumar 2020-09-25 7:25 ` Hector Yuan 0 siblings, 1 reply; 16+ messages in thread From: Viresh Kumar @ 2020-09-25 6:15 UTC (permalink / raw) To: Hector Yuan Cc: Rob Herring, linux-mediatek, linux-arm-kernel, linux-pm, devicetree, Rafael J. Wysocki, linux-kernel, wsd_upstream On 25-09-20, 10:27, Hector Yuan wrote: > Hi, Viresh & Rob Sir: > > I will change frequency domain to below and define it in cpufreq_hw > schema rather than cpu node. > > mediatek,freq-domain-0 = <&cpu0>, <&cpu1>; I think it would be better to do it the standard way we have done it elsewhere. i.e. follow Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt, that is similar to what you did earlier. -- viresh ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v7 2/2] dt-bindings: cpufreq: add bindings for MediaTek cpufreq HW 2020-09-25 6:15 ` Viresh Kumar @ 2020-09-25 7:25 ` Hector Yuan 2020-10-05 2:29 ` Hector Yuan 0 siblings, 1 reply; 16+ messages in thread From: Hector Yuan @ 2020-09-25 7:25 UTC (permalink / raw) To: Viresh Kumar, Rob Herring Cc: Rob Herring, linux-mediatek, linux-arm-kernel, linux-pm, devicetree, Rafael J. Wysocki, linux-kernel, wsd_upstream Hi, Rob sir: Yes, my patch follows Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt way to define frequency domain. Is it OK to you if I use the same way to do? And if there exist any schema problem, please kindly let me know how to fix it. My patch reference Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml to use the cpu node. https://elixir.bootlin.com/linux/v5.9-rc6/source/Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml Thanks a lot. On Fri, 2020-09-25 at 11:45 +0530, Viresh Kumar wrote: > On 25-09-20, 10:27, Hector Yuan wrote: > > Hi, Viresh & Rob Sir: > > > > I will change frequency domain to below and define it in cpufreq_hw > > schema rather than cpu node. > > > > mediatek,freq-domain-0 = <&cpu0>, <&cpu1>; > > I think it would be better to do it the standard way we have done it elsewhere. > i.e. follow Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt, that > is similar to what you did earlier. > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v7 2/2] dt-bindings: cpufreq: add bindings for MediaTek cpufreq HW 2020-09-25 7:25 ` Hector Yuan @ 2020-10-05 2:29 ` Hector Yuan 0 siblings, 0 replies; 16+ messages in thread From: Hector Yuan @ 2020-10-05 2:29 UTC (permalink / raw) To: Rob Herring Cc: linux-mediatek, linux-arm-kernel, linux-pm, devicetree, Rafael J. Wysocki, linux-kernel, wsd_upstream, Viresh Kumar, Viresh Kumar On Fri, 2020-09-25 at 15:25 +0800, Hector Yuan wrote: > Hi, Rob sir: > > Yes, my patch follows > Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt way to > define frequency domain. > Is it OK to you if I use the same way to do? > And if there exist any schema problem, please kindly let me know how to > fix it. > > My patch reference > Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml > to use the cpu node. > https://elixir.bootlin.com/linux/v5.9-rc6/source/Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml > > Thanks a lot. > Hi, Rob sir: Sorry to bother you, may we know your comment for this. Thanks so much. > On Fri, 2020-09-25 at 11:45 +0530, Viresh Kumar wrote: > > On 25-09-20, 10:27, Hector Yuan wrote: > > > Hi, Viresh & Rob Sir: > > > > > > I will change frequency domain to below and define it in cpufreq_hw > > > schema rather than cpu node. > > > > > > mediatek,freq-domain-0 = <&cpu0>, <&cpu1>; > > > > I think it would be better to do it the standard way we have done it elsewhere. > > i.e. follow Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt, that > > is similar to what you did earlier. > > > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v7] cpufreq: mediatek-hw: Add support for Mediatek cpufreq HW driver 2020-09-10 4:31 [PATCH v7] cpufreq: mediatek-hw: Add support for Mediatek cpufreq HW driver Hector Yuan 2020-09-10 4:31 ` [PATCH v7 1/2] " Hector Yuan 2020-09-10 4:31 ` [PATCH v7 2/2] dt-bindings: cpufreq: add bindings for MediaTek cpufreq HW Hector Yuan @ 2020-09-10 5:03 ` Viresh Kumar 2020-09-10 5:30 ` Hector Yuan 2 siblings, 1 reply; 16+ messages in thread From: Viresh Kumar @ 2020-09-10 5:03 UTC (permalink / raw) To: Hector Yuan Cc: linux-mediatek, linux-arm-kernel, linux-pm, devicetree, Rafael J. Wysocki, Rob Herring, linux-kernel, wsd_upstream On 10-09-20, 12:31, Hector Yuan wrote: > The CPUfreq HW present in some Mediatek chipsets offloads the steps necessary for changing the frequency of CPUs. > The driver implements the cpufreq driver interface for this hardware engine. > > This patch depends on the MT6779 DTS patch submitted by Hanks Chen > https://lkml.org/lkml/2020/8/4/1094 Thanks for hanging there. Looks good to me. I will apply it once Rob Ack's the binding patch. -- viresh ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v7] cpufreq: mediatek-hw: Add support for Mediatek cpufreq HW driver 2020-09-10 5:03 ` [PATCH v7] cpufreq: mediatek-hw: Add support for Mediatek cpufreq HW driver Viresh Kumar @ 2020-09-10 5:30 ` Hector Yuan 2020-09-10 5:34 ` Viresh Kumar 0 siblings, 1 reply; 16+ messages in thread From: Hector Yuan @ 2020-09-10 5:30 UTC (permalink / raw) To: Viresh Kumar Cc: linux-mediatek, linux-arm-kernel, linux-pm, devicetree, Rafael J. Wysocki, Rob Herring, linux-kernel, wsd_upstream On Thu, 2020-09-10 at 10:33 +0530, Viresh Kumar wrote: > On 10-09-20, 12:31, Hector Yuan wrote: > > The CPUfreq HW present in some Mediatek chipsets offloads the steps necessary for changing the frequency of CPUs. > > The driver implements the cpufreq driver interface for this hardware engine. > > > > This patch depends on the MT6779 DTS patch submitted by Hanks Chen > > https://lkml.org/lkml/2020/8/4/1094 > > Thanks for hanging there. Looks good to me. I will apply it once Rob > Ack's the binding patch. > Many thanks for your help. May I know if you can add Reviewed-by tag to this patch set. I would like to prepare some patches for more features based on this. Is that okay to you? Thanks again. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v7] cpufreq: mediatek-hw: Add support for Mediatek cpufreq HW driver 2020-09-10 5:30 ` Hector Yuan @ 2020-09-10 5:34 ` Viresh Kumar 2020-09-16 11:39 ` Hector Yuan 0 siblings, 1 reply; 16+ messages in thread From: Viresh Kumar @ 2020-09-10 5:34 UTC (permalink / raw) To: Hector Yuan Cc: linux-mediatek, linux-arm-kernel, linux-pm, devicetree, Rafael J. Wysocki, Rob Herring, linux-kernel, wsd_upstream On 10-09-20, 13:30, Hector Yuan wrote: > On Thu, 2020-09-10 at 10:33 +0530, Viresh Kumar wrote: > > On 10-09-20, 12:31, Hector Yuan wrote: > > > The CPUfreq HW present in some Mediatek chipsets offloads the steps necessary for changing the frequency of CPUs. > > > The driver implements the cpufreq driver interface for this hardware engine. > > > > > > This patch depends on the MT6779 DTS patch submitted by Hanks Chen > > > https://lkml.org/lkml/2020/8/4/1094 > > > > Thanks for hanging there. Looks good to me. I will apply it once Rob > > Ack's the binding patch. > > > > Many thanks for your help. May I know if you can add Reviewed-by tag to > this patch set. Since this patchset is going to get merged via my tree (ARM cpufreq tree), a reviewed-by isn't required here. I will queue it up for 5.10-rc1 after I receive an Ack from Rob. > I would like to prepare some patches for more features > based on this. Is that okay to you? Thanks again. That should be fine. -- viresh ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v7] cpufreq: mediatek-hw: Add support for Mediatek cpufreq HW driver 2020-09-10 5:34 ` Viresh Kumar @ 2020-09-16 11:39 ` Hector Yuan 2020-09-17 2:31 ` Hector Yuan 0 siblings, 1 reply; 16+ messages in thread From: Hector Yuan @ 2020-09-16 11:39 UTC (permalink / raw) To: Viresh Kumar Cc: linux-mediatek, linux-arm-kernel, linux-pm, devicetree, Rafael J. Wysocki, Rob Herring, linux-kernel, wsd_upstream Hi, Rob sir: Sorry to bother you, may I have your review comment for the binding part? Appreciated. On Thu, 2020-09-10 at 11:04 +0530, Viresh Kumar wrote: > On 10-09-20, 13:30, Hector Yuan wrote: > > On Thu, 2020-09-10 at 10:33 +0530, Viresh Kumar wrote: > > > On 10-09-20, 12:31, Hector Yuan wrote: > > > > The CPUfreq HW present in some Mediatek chipsets offloads the steps necessary for changing the frequency of CPUs. > > > > The driver implements the cpufreq driver interface for this hardware engine. > > > > > > > > This patch depends on the MT6779 DTS patch submitted by Hanks Chen > > > > https://lkml.org/lkml/2020/8/4/1094 > > > > > > Thanks for hanging there. Looks good to me. I will apply it once Rob > > > Ack's the binding patch. > > > > > > > Many thanks for your help. May I know if you can add Reviewed-by tag to > > this patch set. > > Since this patchset is going to get merged via my tree (ARM cpufreq > tree), a reviewed-by isn't required here. I will queue it up for > 5.10-rc1 after I receive an Ack from Rob. > > > I would like to prepare some patches for more features > > based on this. Is that okay to you? Thanks again. > > That should be fine. > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v7] cpufreq: mediatek-hw: Add support for Mediatek cpufreq HW driver 2020-09-16 11:39 ` Hector Yuan @ 2020-09-17 2:31 ` Hector Yuan 0 siblings, 0 replies; 16+ messages in thread From: Hector Yuan @ 2020-09-17 2:31 UTC (permalink / raw) To: Rob Herring Cc: Viresh Kumar, linux-mediatek, linux-arm-kernel, linux-pm, devicetree, Rafael J. Wysocki, linux-kernel, wsd_upstream Hi, Rob sir: Sorry to bother you, may I have your review comment for the binding part? Appreciated. On Wed, 2020-09-16 at 19:39 +0800, Hector Yuan wrote: > Hi, Rob sir: > > Sorry to bother you, may I have your review comment for the binding > part? > Appreciated. > > On Thu, 2020-09-10 at 11:04 +0530, Viresh Kumar wrote: > > On 10-09-20, 13:30, Hector Yuan wrote: > > > On Thu, 2020-09-10 at 10:33 +0530, Viresh Kumar wrote: > > > > On 10-09-20, 12:31, Hector Yuan wrote: > > > > > The CPUfreq HW present in some Mediatek chipsets offloads the steps necessary for changing the frequency of CPUs. > > > > > The driver implements the cpufreq driver interface for this hardware engine. > > > > > > > > > > This patch depends on the MT6779 DTS patch submitted by Hanks Chen > > > > > https://lkml.org/lkml/2020/8/4/1094 > > > > > > > > Thanks for hanging there. Looks good to me. I will apply it once Rob > > > > Ack's the binding patch. > > > > > > > > > > Many thanks for your help. May I know if you can add Reviewed-by tag to > > > this patch set. > > > > Since this patchset is going to get merged via my tree (ARM cpufreq > > tree), a reviewed-by isn't required here. I will queue it up for > > 5.10-rc1 after I receive an Ack from Rob. > > > > > I would like to prepare some patches for more features > > > based on this. Is that okay to you? Thanks again. > > > > That should be fine. > > > > ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2020-10-05 2:29 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-09-10 4:31 [PATCH v7] cpufreq: mediatek-hw: Add support for Mediatek cpufreq HW driver Hector Yuan 2020-09-10 4:31 ` [PATCH v7 1/2] " Hector Yuan 2020-09-10 4:31 ` [PATCH v7 2/2] dt-bindings: cpufreq: add bindings for MediaTek cpufreq HW Hector Yuan 2020-09-21 2:23 ` Hector Yuan 2020-09-22 20:28 ` Rob Herring 2020-09-23 13:10 ` Hector Yuan 2020-09-24 2:36 ` Hector Yuan 2020-09-25 2:27 ` Hector Yuan 2020-09-25 6:15 ` Viresh Kumar 2020-09-25 7:25 ` Hector Yuan 2020-10-05 2:29 ` Hector Yuan 2020-09-10 5:03 ` [PATCH v7] cpufreq: mediatek-hw: Add support for Mediatek cpufreq HW driver Viresh Kumar 2020-09-10 5:30 ` Hector Yuan 2020-09-10 5:34 ` Viresh Kumar 2020-09-16 11:39 ` Hector Yuan 2020-09-17 2:31 ` Hector Yuan
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).