[PATCH v2 0/4] Apple SoC cpufreq driver

[PATCH v2 0/4] Apple SoC cpufreq driver

[Hector Martin]

Hi folks,

Here's a second take on the cpufreq driver for Apple SoCs. This is a
complete rewrite using a stand-alone cpufreq driver instead of using the
cpufreq-dt infrastructure.

Since v1 we ran some experiments on the memory controller performance
switching and it turns out it doesn't make a huge difference, so it
makes sense to punt that feature to the future (perhaps once a proper
memory controller driver exists for other reasons, e.g. for error
handling).

One advantage of having a standalone cpufreq driver is that we can
support fast switching. This also means any future interaction with
the memory controller will probably use some bespoke mechanism instead
of the genpd infrastructure, so we can keep the fast path without
allowing sleeps/etc.

The driver is based on scpi-cpufreq.c, with some bits (e.g. the
apple,freq-domain stuff) inspired by how cpufreq-qcom-hw does it.
I'm not sure if that particular property should be described
in a binding, since it goes in the cpu nodes (qcom doesn't have it
anywhere...).

Changes since v1:
- Complete rewrite
- Reports current frequency to userspace properly (incl. if different
  from requested due to hardware constraints)
- Supports fast switching
- MCC latency control stuff no longer included, punted for later
- Supports exposing higher states as turbo states

Hector Martin (4):
  MAINTAINERS: Add entries for Apple SoC cpufreq driver
  dt-bindings: cpufreq: apple,soc-cpufreq: Add binding for Apple SoC
    cpufreq
  cpufreq: apple-soc: Add new driver to control Apple SoC CPU P-states
  arm64: dts: apple: Add CPU topology & cpufreq nodes for t8103

 .../bindings/cpufreq/apple,soc-cpufreq.yaml   | 121 +++++++
 MAINTAINERS                                   |   2 +
 arch/arm64/boot/dts/apple/t8103.dtsi          | 203 ++++++++++-
 drivers/cpufreq/Kconfig.arm                   |   9 +
 drivers/cpufreq/Makefile                      |   1 +
 drivers/cpufreq/apple-soc-cpufreq.c           | 330 ++++++++++++++++++
 drivers/cpufreq/cpufreq-dt-platdev.c          |   2 +
 7 files changed, 658 insertions(+), 10 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/cpufreq/apple,soc-cpufreq.yaml
 create mode 100644 drivers/cpufreq/apple-soc-cpufreq.c

-- 
2.35.1

[PATCH v2 0/4] Apple SoC cpufreq driver

[Hector Martin]

Hi folks,

Here's a second take on the cpufreq driver for Apple SoCs. This is a
complete rewrite using a stand-alone cpufreq driver instead of using the
cpufreq-dt infrastructure.

Since v1 we ran some experiments on the memory controller performance
switching and it turns out it doesn't make a huge difference, so it
makes sense to punt that feature to the future (perhaps once a proper
memory controller driver exists for other reasons, e.g. for error
handling).

One advantage of having a standalone cpufreq driver is that we can
support fast switching. This also means any future interaction with
the memory controller will probably use some bespoke mechanism instead
of the genpd infrastructure, so we can keep the fast path without
allowing sleeps/etc.

The driver is based on scpi-cpufreq.c, with some bits (e.g. the
apple,freq-domain stuff) inspired by how cpufreq-qcom-hw does it.
I'm not sure if that particular property should be described
in a binding, since it goes in the cpu nodes (qcom doesn't have it
anywhere...).

Changes since v1:
- Complete rewrite
- Reports current frequency to userspace properly (incl. if different
  from requested due to hardware constraints)
- Supports fast switching
- MCC latency control stuff no longer included, punted for later
- Supports exposing higher states as turbo states

Hector Martin (4):
  MAINTAINERS: Add entries for Apple SoC cpufreq driver
  dt-bindings: cpufreq: apple,soc-cpufreq: Add binding for Apple SoC
    cpufreq
  cpufreq: apple-soc: Add new driver to control Apple SoC CPU P-states
  arm64: dts: apple: Add CPU topology & cpufreq nodes for t8103

 .../bindings/cpufreq/apple,soc-cpufreq.yaml   | 121 +++++++
 MAINTAINERS                                   |   2 +
 arch/arm64/boot/dts/apple/t8103.dtsi          | 203 ++++++++++-
 drivers/cpufreq/Kconfig.arm                   |   9 +
 drivers/cpufreq/Makefile                      |   1 +
 drivers/cpufreq/apple-soc-cpufreq.c           | 330 ++++++++++++++++++
 drivers/cpufreq/cpufreq-dt-platdev.c          |   2 +
 7 files changed, 658 insertions(+), 10 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/cpufreq/apple,soc-cpufreq.yaml
 create mode 100644 drivers/cpufreq/apple-soc-cpufreq.c

-- 
2.35.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 1/4] MAINTAINERS: Add entries for Apple SoC cpufreq driver

[Hector Martin]

Splitting this commit, as usual, to facilitate merges via the SoC tree.

Signed-off-by: Hector Martin <marcan@marcan.st>
---
 MAINTAINERS | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index edc96cdb85e8..39bfa478fe55 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1835,6 +1835,7 @@ T:	git https://github.com/AsahiLinux/linux.git
 F:	Documentation/devicetree/bindings/arm/apple.yaml
 F:	Documentation/devicetree/bindings/arm/apple/*
 F:	Documentation/devicetree/bindings/clock/apple,nco.yaml
+F:	Documentation/devicetree/bindings/cpufreq/apple,soc-cpufreq.yaml
 F:	Documentation/devicetree/bindings/i2c/apple,i2c.yaml
 F:	Documentation/devicetree/bindings/interrupt-controller/apple,*
 F:	Documentation/devicetree/bindings/mailbox/apple,mailbox.yaml
@@ -1844,6 +1845,7 @@ F:	Documentation/devicetree/bindings/power/apple*
 F:	Documentation/devicetree/bindings/watchdog/apple,wdt.yaml
 F:	arch/arm64/boot/dts/apple/
 F:	drivers/clk/clk-apple-nco.c
+F:	drivers/cpufreq/apple-soc-cpufreq.c
 F:	drivers/i2c/busses/i2c-pasemi-core.c
 F:	drivers/i2c/busses/i2c-pasemi-platform.c
 F:	drivers/irqchip/irq-apple-aic.c
-- 
2.35.1

[PATCH v2 1/4] MAINTAINERS: Add entries for Apple SoC cpufreq driver

[Hector Martin]

Splitting this commit, as usual, to facilitate merges via the SoC tree.

Signed-off-by: Hector Martin <marcan@marcan.st>
---
 MAINTAINERS | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index edc96cdb85e8..39bfa478fe55 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1835,6 +1835,7 @@ T:	git https://github.com/AsahiLinux/linux.git
 F:	Documentation/devicetree/bindings/arm/apple.yaml
 F:	Documentation/devicetree/bindings/arm/apple/*
 F:	Documentation/devicetree/bindings/clock/apple,nco.yaml
+F:	Documentation/devicetree/bindings/cpufreq/apple,soc-cpufreq.yaml
 F:	Documentation/devicetree/bindings/i2c/apple,i2c.yaml
 F:	Documentation/devicetree/bindings/interrupt-controller/apple,*
 F:	Documentation/devicetree/bindings/mailbox/apple,mailbox.yaml
@@ -1844,6 +1845,7 @@ F:	Documentation/devicetree/bindings/power/apple*
 F:	Documentation/devicetree/bindings/watchdog/apple,wdt.yaml
 F:	arch/arm64/boot/dts/apple/
 F:	drivers/clk/clk-apple-nco.c
+F:	drivers/cpufreq/apple-soc-cpufreq.c
 F:	drivers/i2c/busses/i2c-pasemi-core.c
 F:	drivers/i2c/busses/i2c-pasemi-platform.c
 F:	drivers/irqchip/irq-apple-aic.c
-- 
2.35.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 2/4] dt-bindings: cpufreq: apple,soc-cpufreq: Add binding for Apple SoC cpufreq

[Hector Martin]

This binding represents the cpufreq/DVFS hardware present in Apple SoCs.
The hardware has an independent controller per CPU cluster, but we
represent them as a single cpufreq node since there can only be one
systemwide cpufreq device (and since in the future, interactions with
memory controller performance states will also involve cooperation
between multiple frequency domains).

Signed-off-by: Hector Martin <marcan@marcan.st>
---
 .../bindings/cpufreq/apple,soc-cpufreq.yaml   | 121 ++++++++++++++++++
 1 file changed, 121 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/cpufreq/apple,soc-cpufreq.yaml

diff --git a/Documentation/devicetree/bindings/cpufreq/apple,soc-cpufreq.yaml b/Documentation/devicetree/bindings/cpufreq/apple,soc-cpufreq.yaml
new file mode 100644
index 000000000000..f398c1bd5de5
--- /dev/null
+++ b/Documentation/devicetree/bindings/cpufreq/apple,soc-cpufreq.yaml
@@ -0,0 +1,121 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/cpufreq/apple,soc-cpufreq.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Apple SoC cpufreq device
+
+maintainers:
+  - Hector Martin <marcan@marcan.st>
+
+description: |
+  Apple SoCs (e.g. M1) have a per-cpu-cluster DVFS controller that is part of
+  the cluster management register block. This binding uses the standard
+  operating-points-v2 table to define the CPU performance states, with the
+  opp-level property specifying the hardware p-state index for that level.
+
+properties:
+  compatible:
+    items:
+      - enum:
+          - apple,t8103-soc-cpufreq
+          - apple,t6000-soc-cpufreq
+      - const: apple,soc-cpufreq
+
+  reg:
+    minItems: 1
+    maxItems: 6
+    description: One register region per CPU cluster DVFS controller
+
+  reg-names:
+    minItems: 1
+    items:
+      - const: cluster0
+      - const: cluster1
+      - const: cluster2
+      - const: cluster3
+      - const: cluster4
+      - const: cluster5
+
+  '#freq-domain-cells':
+    const: 1
+
+required:
+  - compatible
+  - reg
+  - reg-names
+  - '#freq-domain-cells'
+
+additionalProperties: false
+
+examples:
+  - |
+    // This example shows a single CPU per domain and 2 domains,
+    // with two p-states per domain.
+    // Shipping hardware has 2-4 CPUs per domain and 2-6 domains.
+    cpus {
+      #address-cells = <2>;
+      #size-cells = <0>;
+
+      cpu@0 {
+        compatible = "apple,icestorm";
+        device_type = "cpu";
+        reg = <0x0 0x0>;
+        operating-points-v2 = <&ecluster_opp>;
+        apple,freq-domain = <&cpufreq_hw 0>;
+      };
+
+      cpu@10100 {
+        compatible = "apple,firestorm";
+        device_type = "cpu";
+        reg = <0x0 0x10100>;
+        operating-points-v2 = <&pcluster_opp>;
+        apple,freq-domain = <&cpufreq_hw 1>;
+      };
+    };
+
+    ecluster_opp: opp-table-0 {
+      compatible = "operating-points-v2";
+      opp-shared;
+
+      opp01 {
+        opp-hz = /bits/ 64 <600000000>;
+        opp-level = <1>;
+        clock-latency-ns = <7500>;
+      };
+      opp02 {
+        opp-hz = /bits/ 64 <972000000>;
+        opp-level = <2>;
+        clock-latency-ns = <22000>;
+      };
+    };
+
+    pcluster_opp: opp-table-1 {
+      compatible = "operating-points-v2";
+      opp-shared;
+
+      opp01 {
+        opp-hz = /bits/ 64 <600000000>;
+        opp-level = <1>;
+        clock-latency-ns = <8000>;
+      };
+      opp02 {
+        opp-hz = /bits/ 64 <828000000>;
+        opp-level = <2>;
+        clock-latency-ns = <19000>;
+      };
+    };
+
+    soc {
+      #address-cells = <2>;
+      #size-cells = <2>;
+
+      cpufreq_hw: cpufreq@210e20000 {
+        compatible = "apple,t8103-soc-cpufreq", "apple,soc-cpufreq";
+        reg = <0x2 0x10e20000 0 0x1000>,
+              <0x2 0x11e20000 0 0x1000>;
+        reg-names = "cluster0", "cluster1";
+        #freq-domain-cells = <1>;
+      };
+    };
-- 
2.35.1

[PATCH v2 2/4] dt-bindings: cpufreq: apple, soc-cpufreq: Add binding for Apple SoC cpufreq

[Hector Martin]

This binding represents the cpufreq/DVFS hardware present in Apple SoCs.
The hardware has an independent controller per CPU cluster, but we
represent them as a single cpufreq node since there can only be one
systemwide cpufreq device (and since in the future, interactions with
memory controller performance states will also involve cooperation
between multiple frequency domains).

Signed-off-by: Hector Martin <marcan@marcan.st>
---
 .../bindings/cpufreq/apple,soc-cpufreq.yaml   | 121 ++++++++++++++++++
 1 file changed, 121 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/cpufreq/apple,soc-cpufreq.yaml

diff --git a/Documentation/devicetree/bindings/cpufreq/apple,soc-cpufreq.yaml b/Documentation/devicetree/bindings/cpufreq/apple,soc-cpufreq.yaml
new file mode 100644
index 000000000000..f398c1bd5de5
--- /dev/null
+++ b/Documentation/devicetree/bindings/cpufreq/apple,soc-cpufreq.yaml
@@ -0,0 +1,121 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/cpufreq/apple,soc-cpufreq.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Apple SoC cpufreq device
+
+maintainers:
+  - Hector Martin <marcan@marcan.st>
+
+description: |
+  Apple SoCs (e.g. M1) have a per-cpu-cluster DVFS controller that is part of
+  the cluster management register block. This binding uses the standard
+  operating-points-v2 table to define the CPU performance states, with the
+  opp-level property specifying the hardware p-state index for that level.
+
+properties:
+  compatible:
+    items:
+      - enum:
+          - apple,t8103-soc-cpufreq
+          - apple,t6000-soc-cpufreq
+      - const: apple,soc-cpufreq
+
+  reg:
+    minItems: 1
+    maxItems: 6
+    description: One register region per CPU cluster DVFS controller
+
+  reg-names:
+    minItems: 1
+    items:
+      - const: cluster0
+      - const: cluster1
+      - const: cluster2
+      - const: cluster3
+      - const: cluster4
+      - const: cluster5
+
+  '#freq-domain-cells':
+    const: 1
+
+required:
+  - compatible
+  - reg
+  - reg-names
+  - '#freq-domain-cells'
+
+additionalProperties: false
+
+examples:
+  - |
+    // This example shows a single CPU per domain and 2 domains,
+    // with two p-states per domain.
+    // Shipping hardware has 2-4 CPUs per domain and 2-6 domains.
+    cpus {
+      #address-cells = <2>;
+      #size-cells = <0>;
+
+      cpu@0 {
+        compatible = "apple,icestorm";
+        device_type = "cpu";
+        reg = <0x0 0x0>;
+        operating-points-v2 = <&ecluster_opp>;
+        apple,freq-domain = <&cpufreq_hw 0>;
+      };
+
+      cpu@10100 {
+        compatible = "apple,firestorm";
+        device_type = "cpu";
+        reg = <0x0 0x10100>;
+        operating-points-v2 = <&pcluster_opp>;
+        apple,freq-domain = <&cpufreq_hw 1>;
+      };
+    };
+
+    ecluster_opp: opp-table-0 {
+      compatible = "operating-points-v2";
+      opp-shared;
+
+      opp01 {
+        opp-hz = /bits/ 64 <600000000>;
+        opp-level = <1>;
+        clock-latency-ns = <7500>;
+      };
+      opp02 {
+        opp-hz = /bits/ 64 <972000000>;
+        opp-level = <2>;
+        clock-latency-ns = <22000>;
+      };
+    };
+
+    pcluster_opp: opp-table-1 {
+      compatible = "operating-points-v2";
+      opp-shared;
+
+      opp01 {
+        opp-hz = /bits/ 64 <600000000>;
+        opp-level = <1>;
+        clock-latency-ns = <8000>;
+      };
+      opp02 {
+        opp-hz = /bits/ 64 <828000000>;
+        opp-level = <2>;
+        clock-latency-ns = <19000>;
+      };
+    };
+
+    soc {
+      #address-cells = <2>;
+      #size-cells = <2>;
+
+      cpufreq_hw: cpufreq@210e20000 {
+        compatible = "apple,t8103-soc-cpufreq", "apple,soc-cpufreq";
+        reg = <0x2 0x10e20000 0 0x1000>,
+              <0x2 0x11e20000 0 0x1000>;
+        reg-names = "cluster0", "cluster1";
+        #freq-domain-cells = <1>;
+      };
+    };
-- 
2.35.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 3/4] cpufreq: apple-soc: Add new driver to control Apple SoC CPU P-states

[Hector Martin]

This driver implements CPU frequency scaling for Apple Silicon SoCs,
including M1 (t8103) and M1 Max/Pro/Ultra (t600x).

Each CPU cluster has its own register set, and frequency management is
fully automated by the hardware; the driver only has to write one
register. There is boost frequency support, but the hardware will only
allow their use if only a subset of cores in a cluster are in
non-deep-idle. Since we don't support deep idle yet, these frequencies
are not achievable, but the driver supports them. They will remain
disabled in the device tree until deep idle is implemented, to avoid
confusing users.

This driver does not yet implement the memory controller performance
state tuning that usually accompanies higher CPU p-states. This will be
done in a future patch.

Signed-off-by: Hector Martin <marcan@marcan.st>
---
 drivers/cpufreq/Kconfig.arm          |   9 +
 drivers/cpufreq/Makefile             |   1 +
 drivers/cpufreq/apple-soc-cpufreq.c  | 330 +++++++++++++++++++++++++++
 drivers/cpufreq/cpufreq-dt-platdev.c |   2 +
 4 files changed, 342 insertions(+)
 create mode 100644 drivers/cpufreq/apple-soc-cpufreq.c

diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 954749afb5fe..9a020a0bd9c4 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -41,6 +41,15 @@ config ARM_ALLWINNER_SUN50I_CPUFREQ_NVMEM
 	  To compile this driver as a module, choose M here: the
 	  module will be called sun50i-cpufreq-nvmem.
 
+config ARM_APPLE_SOC_CPUFREQ
+	tristate "Apple Silicon SoC CPUFreq support"
+	depends on ARCH_APPLE || COMPILE_TEST
+	select PM_OPP
+	default ARCH_APPLE
+	help
+	  This adds the CPUFreq driver for Apple Silicon machines
+	  (e.g. Apple M1).
+
 config ARM_ARMADA_37XX_CPUFREQ
 	tristate "Armada 37xx CPUFreq support"
 	depends on ARCH_MVEBU && CPUFREQ_DT
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 285de70af877..c0da6f2f6cd5 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -51,6 +51,7 @@ obj-$(CONFIG_X86_AMD_FREQ_SENSITIVITY)	+= amd_freq_sensitivity.o
 
 ##################################################################################
 # ARM SoC drivers
+obj-$(CONFIG_ARM_APPLE_SOC_CPUFREQ)	+= apple-soc-cpufreq.o
 obj-$(CONFIG_ARM_ARMADA_37XX_CPUFREQ)	+= armada-37xx-cpufreq.o
 obj-$(CONFIG_ARM_ARMADA_8K_CPUFREQ)	+= armada-8k-cpufreq.o
 obj-$(CONFIG_ARM_BRCMSTB_AVS_CPUFREQ)	+= brcmstb-avs-cpufreq.o
diff --git a/drivers/cpufreq/apple-soc-cpufreq.c b/drivers/cpufreq/apple-soc-cpufreq.c
new file mode 100644
index 000000000000..191eaae71744
--- /dev/null
+++ b/drivers/cpufreq/apple-soc-cpufreq.c
@@ -0,0 +1,330 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Apple SoC CPU cluster performance state driver
+ *
+ * Copyright The Asahi Linux Contributors
+ *
+ * Based on scpi-cpufreq.c
+ */
+
+#include <linux/bitfield.h>
+#include <linux/bitops.h>
+#include <linux/cpu.h>
+#include <linux/cpufreq.h>
+#include <linux/cpumask.h>
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/platform_device.h>
+#include <linux/pm_opp.h>
+#include <linux/slab.h>
+
+#define APPLE_DVFS_CMD			0x20
+#define APPLE_DVFS_CMD_BUSY		BIT(31)
+#define APPLE_DVFS_CMD_SET		BIT(25)
+#define APPLE_DVFS_CMD_PS2		GENMASK(15, 12)
+#define APPLE_DVFS_CMD_PS1		GENMASK(3, 0)
+
+/* Same timebase as CPU counter (24MHz) */
+#define APPLE_DVFS_LAST_CHG_TIME	0x38
+
+#define APPLE_DVFS_STATUS		0x50
+#define APPLE_DVFS_STATUS_CUR_PS	GENMASK(7, 4)
+#define APPLE_DVFS_STATUS_TGT_PS	GENMASK(3, 0)
+
+/*
+ * Div is +1, base clock is 12MHz on existing SoCs.
+ * For documentation purposes. We use the OPP table to
+ * get the frequency.
+ */
+#define APPLE_DVFS_PLL_STATUS		0xc0
+#define APPLE_DVFS_PLL_FACTOR		0xc8
+#define APPLE_DVFS_PLL_FACTOR_MULT	GENMASK(31, 16)
+#define APPLE_DVFS_PLL_FACTOR_DIV	GENMASK(15, 0)
+
+struct apple_cpu_priv {
+	struct device *cpu_dev;
+	void __iomem *reg_base;
+};
+
+struct apple_soc_cpufreq_priv {
+	struct device *dev;
+	void __iomem *reg_base;
+};
+
+#define APPLE_DVFS_TRANSITION_TIMEOUT 100
+
+static struct cpufreq_driver apple_soc_cpufreq_driver;
+
+static unsigned int apple_soc_cpufreq_get_rate(unsigned int cpu)
+{
+	struct cpufreq_policy *policy = cpufreq_cpu_get_raw(cpu);
+	struct apple_cpu_priv *priv = policy->driver_data;
+	u64 reg = readq_relaxed(priv->reg_base + APPLE_DVFS_STATUS);
+	unsigned int pstate = FIELD_GET(APPLE_DVFS_STATUS_CUR_PS, reg);
+	unsigned int i;
+
+	for (i = 0; policy->freq_table[i].frequency != CPUFREQ_TABLE_END; i++)
+		if (policy->freq_table[i].driver_data == pstate)
+			return policy->freq_table[i].frequency;
+
+	dev_err(priv->cpu_dev, "could not find frequency for pstate %d\n",
+		pstate);
+	return 0;
+}
+
+static int apple_soc_cpufreq_set_target(struct cpufreq_policy *policy,
+					unsigned int index)
+{
+	struct apple_cpu_priv *priv = policy->driver_data;
+	unsigned int pstate = policy->freq_table[index].driver_data;
+	u64 reg;
+
+	if (readq_poll_timeout_atomic(priv->reg_base + APPLE_DVFS_CMD, reg,
+				      !(reg & APPLE_DVFS_CMD_BUSY), 2,
+				      APPLE_DVFS_TRANSITION_TIMEOUT)) {
+		return -EIO;
+	}
+
+	reg &= ~(APPLE_DVFS_CMD_PS1 | APPLE_DVFS_CMD_PS2);
+	reg |= FIELD_PREP(APPLE_DVFS_CMD_PS1, pstate);
+	reg |= FIELD_PREP(APPLE_DVFS_CMD_PS2, pstate);
+	reg |= APPLE_DVFS_CMD_SET;
+
+	writeq_relaxed(reg, priv->reg_base + APPLE_DVFS_CMD);
+
+	return 0;
+}
+
+static unsigned int apple_soc_cpufreq_fast_switch(struct cpufreq_policy *policy,
+						  unsigned int target_freq)
+{
+	if (apple_soc_cpufreq_set_target(policy, policy->cached_resolved_idx) < 0)
+		return 0;
+
+	return policy->freq_table[policy->cached_resolved_idx].frequency;
+}
+
+static int apple_soc_cpufreq_find_cluster(struct cpufreq_policy *policy,
+					  void __iomem **reg_base)
+{
+	struct of_phandle_args args;
+	struct device_node *cpu_np;
+	char name[32];
+	int cpu, ret;
+	int index;
+
+	cpu_np = of_cpu_device_node_get(policy->cpu);
+	if (!cpu_np)
+		return -EINVAL;
+
+	ret = of_parse_phandle_with_args(cpu_np, "apple,freq-domain",
+					 "#freq-domain-cells", 0, &args);
+	of_node_put(cpu_np);
+	if (ret)
+		return ret;
+
+	index = args.args[0];
+
+	snprintf(name, sizeof(name), "cluster%d", index);
+	ret = of_property_match_string(args.np, "reg-names", name);
+	if (ret < 0)
+		return ret;
+
+	*reg_base = of_iomap(args.np, ret);
+	if (IS_ERR(*reg_base))
+		return PTR_ERR(*reg_base);
+
+	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, "apple,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, policy->cpus);
+	}
+
+	return 0;
+}
+
+static struct freq_attr *apple_soc_cpufreq_hw_attr[] = {
+	&cpufreq_freq_attr_scaling_available_freqs,
+	NULL,
+	NULL,
+};
+
+static int apple_soc_cpufreq_init(struct cpufreq_policy *policy)
+{
+	int ret, i;
+	unsigned int transition_latency;
+	void __iomem *reg_base;
+	struct device *cpu_dev;
+	struct apple_cpu_priv *priv;
+	struct cpufreq_frequency_table *freq_table;
+
+	cpu_dev = get_cpu_device(policy->cpu);
+	if (!cpu_dev) {
+		pr_err("failed to get cpu%d device\n", policy->cpu);
+		return -ENODEV;
+	}
+
+	ret = dev_pm_opp_of_add_table(cpu_dev);
+	if (ret < 0) {
+		dev_err(cpu_dev, "%s: failed to add OPP table: %d\n", __func__, ret);
+		return ret;
+	}
+
+	ret = apple_soc_cpufreq_find_cluster(policy, &reg_base);
+	if (ret) {
+		dev_err(cpu_dev, "%s: failed to get cluster info: %d\n", __func__, ret);
+		return ret;
+	}
+
+	ret = dev_pm_opp_set_sharing_cpus(cpu_dev, policy->cpus);
+	if (ret) {
+		dev_err(cpu_dev, "%s: failed to mark OPPs as shared: %d\n", __func__, ret);
+		goto out_iounmap;
+	}
+
+	ret = dev_pm_opp_get_opp_count(cpu_dev);
+	if (ret <= 0) {
+		dev_dbg(cpu_dev, "OPP table is not ready, deferring probe\n");
+		ret = -EPROBE_DEFER;
+		goto out_free_opp;
+	}
+
+	priv = kzalloc(sizeof(*priv), GFP_KERNEL);
+	if (!priv) {
+		ret = -ENOMEM;
+		goto out_free_opp;
+	}
+
+	ret = dev_pm_opp_init_cpufreq_table(cpu_dev, &freq_table);
+	if (ret) {
+		dev_err(cpu_dev, "failed to init cpufreq table: %d\n", ret);
+		goto out_free_priv;
+	}
+
+	/* Get OPP levels (p-state indexes) and stash them in driver_data */
+	for (i = 0; freq_table[i].frequency != CPUFREQ_TABLE_END; i++) {
+		unsigned long rate = freq_table[i].frequency * 1000;
+		struct dev_pm_opp *opp = dev_pm_opp_find_freq_floor(cpu_dev, &rate);
+
+		if (IS_ERR(opp)) {
+			ret = PTR_ERR(opp);
+			goto out_free_cpufreq_table;
+		}
+		freq_table[i].driver_data = dev_pm_opp_get_level(opp);
+		dev_pm_opp_put(opp);
+	}
+
+	priv->cpu_dev = cpu_dev;
+	priv->reg_base = reg_base;
+	policy->driver_data = priv;
+	policy->freq_table = freq_table;
+
+	transition_latency = dev_pm_opp_get_max_transition_latency(cpu_dev);
+	if (!transition_latency)
+		transition_latency = CPUFREQ_ETERNAL;
+
+	policy->cpuinfo.transition_latency = transition_latency;
+	policy->dvfs_possible_from_any_cpu = true;
+	policy->fast_switch_possible = true;
+
+	if (policy_has_boost_freq(policy)) {
+		ret = cpufreq_enable_boost_support();
+		if (ret) {
+			dev_warn(cpu_dev, "failed to enable boost: %d\n", ret);
+		} else {
+			apple_soc_cpufreq_hw_attr[1] = &cpufreq_freq_attr_scaling_boost_freqs;
+			apple_soc_cpufreq_driver.boost_enabled = true;
+		}
+	}
+
+	return 0;
+
+out_free_cpufreq_table:
+	dev_pm_opp_free_cpufreq_table(cpu_dev, &freq_table);
+out_free_priv:
+	kfree(priv);
+out_free_opp:
+	dev_pm_opp_remove_all_dynamic(cpu_dev);
+out_iounmap:
+	iounmap(reg_base);
+	return ret;
+}
+
+static int apple_soc_cpufreq_exit(struct cpufreq_policy *policy)
+{
+	struct apple_cpu_priv *priv = policy->driver_data;
+
+	dev_pm_opp_free_cpufreq_table(priv->cpu_dev, &policy->freq_table);
+	dev_pm_opp_remove_all_dynamic(priv->cpu_dev);
+	iounmap(priv->reg_base);
+	kfree(priv);
+
+	return 0;
+}
+
+static struct cpufreq_driver apple_soc_cpufreq_driver = {
+	.name		= "apple-cpufreq",
+	.flags		= CPUFREQ_HAVE_GOVERNOR_PER_POLICY |
+			  CPUFREQ_NEED_INITIAL_FREQ_CHECK | CPUFREQ_IS_COOLING_DEV,
+	.verify		= cpufreq_generic_frequency_table_verify,
+	.attr		= cpufreq_generic_attr,
+	.get		= apple_soc_cpufreq_get_rate,
+	.init		= apple_soc_cpufreq_init,
+	.exit		= apple_soc_cpufreq_exit,
+	.target_index	= apple_soc_cpufreq_set_target,
+	.fast_switch	= apple_soc_cpufreq_fast_switch,
+	.register_em	= cpufreq_register_em_with_opp,
+	.attr		= apple_soc_cpufreq_hw_attr,
+};
+
+static int apple_soc_cpufreq_probe(struct platform_device *pdev)
+{
+	int ret;
+
+	ret = cpufreq_register_driver(&apple_soc_cpufreq_driver);
+	if (ret)
+		return dev_err_probe(&pdev->dev, ret, "registering cpufreq failed\n");
+
+	return 0;
+}
+
+static int apple_soc_cpufreq_remove(struct platform_device *pdev)
+{
+	cpufreq_unregister_driver(&apple_soc_cpufreq_driver);
+
+	return 0;
+}
+
+static const struct of_device_id apple_soc_cpufreq_of_match[] = {
+	{ .compatible = "apple,soc-cpufreq" },
+	{}
+};
+MODULE_DEVICE_TABLE(of, apple_soc_cpufreq_of_match);
+
+static struct platform_driver apple_soc_cpufreq_plat_driver = {
+	.probe		= apple_soc_cpufreq_probe,
+	.remove		= apple_soc_cpufreq_remove,
+	.driver = {
+		.name	= "apple-soc-cpufreq",
+		.of_match_table = apple_soc_cpufreq_of_match,
+	},
+};
+module_platform_driver(apple_soc_cpufreq_plat_driver);
+
+MODULE_AUTHOR("Hector Martin <marcan@marcan.st>");
+MODULE_DESCRIPTION("Apple SoC CPU cluster DVFS driver");
+MODULE_LICENSE("GPL");
diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
index 96de1536e1cb..2cb54206a4ae 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -103,6 +103,8 @@ static const struct of_device_id allowlist[] __initconst = {
 static const struct of_device_id blocklist[] __initconst = {
 	{ .compatible = "allwinner,sun50i-h6", },
 
+	{ .compatible = "apple,arm-platform", },
+
 	{ .compatible = "arm,vexpress", },
 
 	{ .compatible = "calxeda,highbank", },
-- 
2.35.1

[PATCH v2 3/4] cpufreq: apple-soc: Add new driver to control Apple SoC CPU P-states

[Hector Martin]

This driver implements CPU frequency scaling for Apple Silicon SoCs,
including M1 (t8103) and M1 Max/Pro/Ultra (t600x).

Each CPU cluster has its own register set, and frequency management is
fully automated by the hardware; the driver only has to write one
register. There is boost frequency support, but the hardware will only
allow their use if only a subset of cores in a cluster are in
non-deep-idle. Since we don't support deep idle yet, these frequencies
are not achievable, but the driver supports them. They will remain
disabled in the device tree until deep idle is implemented, to avoid
confusing users.

This driver does not yet implement the memory controller performance
state tuning that usually accompanies higher CPU p-states. This will be
done in a future patch.

Signed-off-by: Hector Martin <marcan@marcan.st>
---
 drivers/cpufreq/Kconfig.arm          |   9 +
 drivers/cpufreq/Makefile             |   1 +
 drivers/cpufreq/apple-soc-cpufreq.c  | 330 +++++++++++++++++++++++++++
 drivers/cpufreq/cpufreq-dt-platdev.c |   2 +
 4 files changed, 342 insertions(+)
 create mode 100644 drivers/cpufreq/apple-soc-cpufreq.c

diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 954749afb5fe..9a020a0bd9c4 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -41,6 +41,15 @@ config ARM_ALLWINNER_SUN50I_CPUFREQ_NVMEM
 	  To compile this driver as a module, choose M here: the
 	  module will be called sun50i-cpufreq-nvmem.
 
+config ARM_APPLE_SOC_CPUFREQ
+	tristate "Apple Silicon SoC CPUFreq support"
+	depends on ARCH_APPLE || COMPILE_TEST
+	select PM_OPP
+	default ARCH_APPLE
+	help
+	  This adds the CPUFreq driver for Apple Silicon machines
+	  (e.g. Apple M1).
+
 config ARM_ARMADA_37XX_CPUFREQ
 	tristate "Armada 37xx CPUFreq support"
 	depends on ARCH_MVEBU && CPUFREQ_DT
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 285de70af877..c0da6f2f6cd5 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -51,6 +51,7 @@ obj-$(CONFIG_X86_AMD_FREQ_SENSITIVITY)	+= amd_freq_sensitivity.o
 
 ##################################################################################
 # ARM SoC drivers
+obj-$(CONFIG_ARM_APPLE_SOC_CPUFREQ)	+= apple-soc-cpufreq.o
 obj-$(CONFIG_ARM_ARMADA_37XX_CPUFREQ)	+= armada-37xx-cpufreq.o
 obj-$(CONFIG_ARM_ARMADA_8K_CPUFREQ)	+= armada-8k-cpufreq.o
 obj-$(CONFIG_ARM_BRCMSTB_AVS_CPUFREQ)	+= brcmstb-avs-cpufreq.o
diff --git a/drivers/cpufreq/apple-soc-cpufreq.c b/drivers/cpufreq/apple-soc-cpufreq.c
new file mode 100644
index 000000000000..191eaae71744
--- /dev/null
+++ b/drivers/cpufreq/apple-soc-cpufreq.c
@@ -0,0 +1,330 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Apple SoC CPU cluster performance state driver
+ *
+ * Copyright The Asahi Linux Contributors
+ *
+ * Based on scpi-cpufreq.c
+ */
+
+#include <linux/bitfield.h>
+#include <linux/bitops.h>
+#include <linux/cpu.h>
+#include <linux/cpufreq.h>
+#include <linux/cpumask.h>
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/platform_device.h>
+#include <linux/pm_opp.h>
+#include <linux/slab.h>
+
+#define APPLE_DVFS_CMD			0x20
+#define APPLE_DVFS_CMD_BUSY		BIT(31)
+#define APPLE_DVFS_CMD_SET		BIT(25)
+#define APPLE_DVFS_CMD_PS2		GENMASK(15, 12)
+#define APPLE_DVFS_CMD_PS1		GENMASK(3, 0)
+
+/* Same timebase as CPU counter (24MHz) */
+#define APPLE_DVFS_LAST_CHG_TIME	0x38
+
+#define APPLE_DVFS_STATUS		0x50
+#define APPLE_DVFS_STATUS_CUR_PS	GENMASK(7, 4)
+#define APPLE_DVFS_STATUS_TGT_PS	GENMASK(3, 0)
+
+/*
+ * Div is +1, base clock is 12MHz on existing SoCs.
+ * For documentation purposes. We use the OPP table to
+ * get the frequency.
+ */
+#define APPLE_DVFS_PLL_STATUS		0xc0
+#define APPLE_DVFS_PLL_FACTOR		0xc8
+#define APPLE_DVFS_PLL_FACTOR_MULT	GENMASK(31, 16)
+#define APPLE_DVFS_PLL_FACTOR_DIV	GENMASK(15, 0)
+
+struct apple_cpu_priv {
+	struct device *cpu_dev;
+	void __iomem *reg_base;
+};
+
+struct apple_soc_cpufreq_priv {
+	struct device *dev;
+	void __iomem *reg_base;
+};
+
+#define APPLE_DVFS_TRANSITION_TIMEOUT 100
+
+static struct cpufreq_driver apple_soc_cpufreq_driver;
+
+static unsigned int apple_soc_cpufreq_get_rate(unsigned int cpu)
+{
+	struct cpufreq_policy *policy = cpufreq_cpu_get_raw(cpu);
+	struct apple_cpu_priv *priv = policy->driver_data;
+	u64 reg = readq_relaxed(priv->reg_base + APPLE_DVFS_STATUS);
+	unsigned int pstate = FIELD_GET(APPLE_DVFS_STATUS_CUR_PS, reg);
+	unsigned int i;
+
+	for (i = 0; policy->freq_table[i].frequency != CPUFREQ_TABLE_END; i++)
+		if (policy->freq_table[i].driver_data == pstate)
+			return policy->freq_table[i].frequency;
+
+	dev_err(priv->cpu_dev, "could not find frequency for pstate %d\n",
+		pstate);
+	return 0;
+}
+
+static int apple_soc_cpufreq_set_target(struct cpufreq_policy *policy,
+					unsigned int index)
+{
+	struct apple_cpu_priv *priv = policy->driver_data;
+	unsigned int pstate = policy->freq_table[index].driver_data;
+	u64 reg;
+
+	if (readq_poll_timeout_atomic(priv->reg_base + APPLE_DVFS_CMD, reg,
+				      !(reg & APPLE_DVFS_CMD_BUSY), 2,
+				      APPLE_DVFS_TRANSITION_TIMEOUT)) {
+		return -EIO;
+	}
+
+	reg &= ~(APPLE_DVFS_CMD_PS1 | APPLE_DVFS_CMD_PS2);
+	reg |= FIELD_PREP(APPLE_DVFS_CMD_PS1, pstate);
+	reg |= FIELD_PREP(APPLE_DVFS_CMD_PS2, pstate);
+	reg |= APPLE_DVFS_CMD_SET;
+
+	writeq_relaxed(reg, priv->reg_base + APPLE_DVFS_CMD);
+
+	return 0;
+}
+
+static unsigned int apple_soc_cpufreq_fast_switch(struct cpufreq_policy *policy,
+						  unsigned int target_freq)
+{
+	if (apple_soc_cpufreq_set_target(policy, policy->cached_resolved_idx) < 0)
+		return 0;
+
+	return policy->freq_table[policy->cached_resolved_idx].frequency;
+}
+
+static int apple_soc_cpufreq_find_cluster(struct cpufreq_policy *policy,
+					  void __iomem **reg_base)
+{
+	struct of_phandle_args args;
+	struct device_node *cpu_np;
+	char name[32];
+	int cpu, ret;
+	int index;
+
+	cpu_np = of_cpu_device_node_get(policy->cpu);
+	if (!cpu_np)
+		return -EINVAL;
+
+	ret = of_parse_phandle_with_args(cpu_np, "apple,freq-domain",
+					 "#freq-domain-cells", 0, &args);
+	of_node_put(cpu_np);
+	if (ret)
+		return ret;
+
+	index = args.args[0];
+
+	snprintf(name, sizeof(name), "cluster%d", index);
+	ret = of_property_match_string(args.np, "reg-names", name);
+	if (ret < 0)
+		return ret;
+
+	*reg_base = of_iomap(args.np, ret);
+	if (IS_ERR(*reg_base))
+		return PTR_ERR(*reg_base);
+
+	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, "apple,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, policy->cpus);
+	}
+
+	return 0;
+}
+
+static struct freq_attr *apple_soc_cpufreq_hw_attr[] = {
+	&cpufreq_freq_attr_scaling_available_freqs,
+	NULL,
+	NULL,
+};
+
+static int apple_soc_cpufreq_init(struct cpufreq_policy *policy)
+{
+	int ret, i;
+	unsigned int transition_latency;
+	void __iomem *reg_base;
+	struct device *cpu_dev;
+	struct apple_cpu_priv *priv;
+	struct cpufreq_frequency_table *freq_table;
+
+	cpu_dev = get_cpu_device(policy->cpu);
+	if (!cpu_dev) {
+		pr_err("failed to get cpu%d device\n", policy->cpu);
+		return -ENODEV;
+	}
+
+	ret = dev_pm_opp_of_add_table(cpu_dev);
+	if (ret < 0) {
+		dev_err(cpu_dev, "%s: failed to add OPP table: %d\n", __func__, ret);
+		return ret;
+	}
+
+	ret = apple_soc_cpufreq_find_cluster(policy, &reg_base);
+	if (ret) {
+		dev_err(cpu_dev, "%s: failed to get cluster info: %d\n", __func__, ret);
+		return ret;
+	}
+
+	ret = dev_pm_opp_set_sharing_cpus(cpu_dev, policy->cpus);
+	if (ret) {
+		dev_err(cpu_dev, "%s: failed to mark OPPs as shared: %d\n", __func__, ret);
+		goto out_iounmap;
+	}
+
+	ret = dev_pm_opp_get_opp_count(cpu_dev);
+	if (ret <= 0) {
+		dev_dbg(cpu_dev, "OPP table is not ready, deferring probe\n");
+		ret = -EPROBE_DEFER;
+		goto out_free_opp;
+	}
+
+	priv = kzalloc(sizeof(*priv), GFP_KERNEL);
+	if (!priv) {
+		ret = -ENOMEM;
+		goto out_free_opp;
+	}
+
+	ret = dev_pm_opp_init_cpufreq_table(cpu_dev, &freq_table);
+	if (ret) {
+		dev_err(cpu_dev, "failed to init cpufreq table: %d\n", ret);
+		goto out_free_priv;
+	}
+
+	/* Get OPP levels (p-state indexes) and stash them in driver_data */
+	for (i = 0; freq_table[i].frequency != CPUFREQ_TABLE_END; i++) {
+		unsigned long rate = freq_table[i].frequency * 1000;
+		struct dev_pm_opp *opp = dev_pm_opp_find_freq_floor(cpu_dev, &rate);
+
+		if (IS_ERR(opp)) {
+			ret = PTR_ERR(opp);
+			goto out_free_cpufreq_table;
+		}
+		freq_table[i].driver_data = dev_pm_opp_get_level(opp);
+		dev_pm_opp_put(opp);
+	}
+
+	priv->cpu_dev = cpu_dev;
+	priv->reg_base = reg_base;
+	policy->driver_data = priv;
+	policy->freq_table = freq_table;
+
+	transition_latency = dev_pm_opp_get_max_transition_latency(cpu_dev);
+	if (!transition_latency)
+		transition_latency = CPUFREQ_ETERNAL;
+
+	policy->cpuinfo.transition_latency = transition_latency;
+	policy->dvfs_possible_from_any_cpu = true;
+	policy->fast_switch_possible = true;
+
+	if (policy_has_boost_freq(policy)) {
+		ret = cpufreq_enable_boost_support();
+		if (ret) {
+			dev_warn(cpu_dev, "failed to enable boost: %d\n", ret);
+		} else {
+			apple_soc_cpufreq_hw_attr[1] = &cpufreq_freq_attr_scaling_boost_freqs;
+			apple_soc_cpufreq_driver.boost_enabled = true;
+		}
+	}
+
+	return 0;
+
+out_free_cpufreq_table:
+	dev_pm_opp_free_cpufreq_table(cpu_dev, &freq_table);
+out_free_priv:
+	kfree(priv);
+out_free_opp:
+	dev_pm_opp_remove_all_dynamic(cpu_dev);
+out_iounmap:
+	iounmap(reg_base);
+	return ret;
+}
+
+static int apple_soc_cpufreq_exit(struct cpufreq_policy *policy)
+{
+	struct apple_cpu_priv *priv = policy->driver_data;
+
+	dev_pm_opp_free_cpufreq_table(priv->cpu_dev, &policy->freq_table);
+	dev_pm_opp_remove_all_dynamic(priv->cpu_dev);
+	iounmap(priv->reg_base);
+	kfree(priv);
+
+	return 0;
+}
+
+static struct cpufreq_driver apple_soc_cpufreq_driver = {
+	.name		= "apple-cpufreq",
+	.flags		= CPUFREQ_HAVE_GOVERNOR_PER_POLICY |
+			  CPUFREQ_NEED_INITIAL_FREQ_CHECK | CPUFREQ_IS_COOLING_DEV,
+	.verify		= cpufreq_generic_frequency_table_verify,
+	.attr		= cpufreq_generic_attr,
+	.get		= apple_soc_cpufreq_get_rate,
+	.init		= apple_soc_cpufreq_init,
+	.exit		= apple_soc_cpufreq_exit,
+	.target_index	= apple_soc_cpufreq_set_target,
+	.fast_switch	= apple_soc_cpufreq_fast_switch,
+	.register_em	= cpufreq_register_em_with_opp,
+	.attr		= apple_soc_cpufreq_hw_attr,
+};
+
+static int apple_soc_cpufreq_probe(struct platform_device *pdev)
+{
+	int ret;
+
+	ret = cpufreq_register_driver(&apple_soc_cpufreq_driver);
+	if (ret)
+		return dev_err_probe(&pdev->dev, ret, "registering cpufreq failed\n");
+
+	return 0;
+}
+
+static int apple_soc_cpufreq_remove(struct platform_device *pdev)
+{
+	cpufreq_unregister_driver(&apple_soc_cpufreq_driver);
+
+	return 0;
+}
+
+static const struct of_device_id apple_soc_cpufreq_of_match[] = {
+	{ .compatible = "apple,soc-cpufreq" },
+	{}
+};
+MODULE_DEVICE_TABLE(of, apple_soc_cpufreq_of_match);
+
+static struct platform_driver apple_soc_cpufreq_plat_driver = {
+	.probe		= apple_soc_cpufreq_probe,
+	.remove		= apple_soc_cpufreq_remove,
+	.driver = {
+		.name	= "apple-soc-cpufreq",
+		.of_match_table = apple_soc_cpufreq_of_match,
+	},
+};
+module_platform_driver(apple_soc_cpufreq_plat_driver);
+
+MODULE_AUTHOR("Hector Martin <marcan@marcan.st>");
+MODULE_DESCRIPTION("Apple SoC CPU cluster DVFS driver");
+MODULE_LICENSE("GPL");
diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
index 96de1536e1cb..2cb54206a4ae 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -103,6 +103,8 @@ static const struct of_device_id allowlist[] __initconst = {
 static const struct of_device_id blocklist[] __initconst = {
 	{ .compatible = "allwinner,sun50i-h6", },
 
+	{ .compatible = "apple,arm-platform", },
+
 	{ .compatible = "arm,vexpress", },
 
 	{ .compatible = "calxeda,highbank", },
-- 
2.35.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 4/4] arm64: dts: apple: Add CPU topology & cpufreq nodes for t8103

[Hector Martin]

Add the missing CPU topology/capacity information and the cpufreq nodes,
so we can have CPU frequency scaling and the scheduler has the
information it needs to make the correct decisions.

Boost states are commented out, as they are not yet available (that
requires CPU deep sleep support, to be eventually done via PSCI).
The driver supports them fine; the hardware will just refuse to ever
go into them at this time, so don't expose them to users until that's
done.

Signed-off-by: Hector Martin <marcan@marcan.st>
---
 arch/arm64/boot/dts/apple/t8103.dtsi | 203 +++++++++++++++++++++++++--
 1 file changed, 193 insertions(+), 10 deletions(-)

diff --git a/arch/arm64/boot/dts/apple/t8103.dtsi b/arch/arm64/boot/dts/apple/t8103.dtsi
index 9f8f4145db88..3df126a5a7dd 100644
--- a/arch/arm64/boot/dts/apple/t8103.dtsi
+++ b/arch/arm64/boot/dts/apple/t8103.dtsi
@@ -22,71 +22,245 @@ cpus {
 		#address-cells = <2>;
 		#size-cells = <0>;
 
-		cpu0: cpu@0 {
+		cpu-map {
+			cluster0 {
+				core0 {
+					cpu = <&cpu_e0>;
+				};
+				core1 {
+					cpu = <&cpu_e1>;
+				};
+				core2 {
+					cpu = <&cpu_e2>;
+				};
+				core3 {
+					cpu = <&cpu_e3>;
+				};
+			};
+
+			cluster1 {
+				core0 {
+					cpu = <&cpu_p0>;
+				};
+				core1 {
+					cpu = <&cpu_p1>;
+				};
+				core2 {
+					cpu = <&cpu_p2>;
+				};
+				core3 {
+					cpu = <&cpu_p3>;
+				};
+			};
+		};
+
+		cpu_e0: cpu@0 {
 			compatible = "apple,icestorm";
 			device_type = "cpu";
 			reg = <0x0 0x0>;
 			enable-method = "spin-table";
 			cpu-release-addr = <0 0>; /* To be filled by loader */
+			operating-points-v2 = <&ecluster_opp>;
+			capacity-dmips-mhz = <714>;
+			apple,freq-domain = <&cpufreq_hw 0>;
 		};
 
-		cpu1: cpu@1 {
+		cpu_e1: cpu@1 {
 			compatible = "apple,icestorm";
 			device_type = "cpu";
 			reg = <0x0 0x1>;
 			enable-method = "spin-table";
 			cpu-release-addr = <0 0>; /* To be filled by loader */
+			operating-points-v2 = <&ecluster_opp>;
+			capacity-dmips-mhz = <714>;
+			apple,freq-domain = <&cpufreq_hw 0>;
 		};
 
-		cpu2: cpu@2 {
+		cpu_e2: cpu@2 {
 			compatible = "apple,icestorm";
 			device_type = "cpu";
 			reg = <0x0 0x2>;
 			enable-method = "spin-table";
 			cpu-release-addr = <0 0>; /* To be filled by loader */
+			operating-points-v2 = <&ecluster_opp>;
+			capacity-dmips-mhz = <714>;
+			apple,freq-domain = <&cpufreq_hw 0>;
 		};
 
-		cpu3: cpu@3 {
+		cpu_e3: cpu@3 {
 			compatible = "apple,icestorm";
 			device_type = "cpu";
 			reg = <0x0 0x3>;
 			enable-method = "spin-table";
 			cpu-release-addr = <0 0>; /* To be filled by loader */
+			operating-points-v2 = <&ecluster_opp>;
+			capacity-dmips-mhz = <714>;
+			apple,freq-domain = <&cpufreq_hw 0>;
 		};
 
-		cpu4: cpu@10100 {
+		cpu_p0: cpu@10100 {
 			compatible = "apple,firestorm";
 			device_type = "cpu";
 			reg = <0x0 0x10100>;
 			enable-method = "spin-table";
 			cpu-release-addr = <0 0>; /* To be filled by loader */
+			operating-points-v2 = <&pcluster_opp>;
+			capacity-dmips-mhz = <1024>;
+			apple,freq-domain = <&cpufreq_hw 1>;
 		};
 
-		cpu5: cpu@10101 {
+		cpu_p1: cpu@10101 {
 			compatible = "apple,firestorm";
 			device_type = "cpu";
 			reg = <0x0 0x10101>;
 			enable-method = "spin-table";
 			cpu-release-addr = <0 0>; /* To be filled by loader */
+			operating-points-v2 = <&pcluster_opp>;
+			capacity-dmips-mhz = <1024>;
+			apple,freq-domain = <&cpufreq_hw 1>;
 		};
 
-		cpu6: cpu@10102 {
+		cpu_p2: cpu@10102 {
 			compatible = "apple,firestorm";
 			device_type = "cpu";
 			reg = <0x0 0x10102>;
 			enable-method = "spin-table";
 			cpu-release-addr = <0 0>; /* To be filled by loader */
+			operating-points-v2 = <&pcluster_opp>;
+			capacity-dmips-mhz = <1024>;
+			apple,freq-domain = <&cpufreq_hw 1>;
 		};
 
-		cpu7: cpu@10103 {
+		cpu_p3: cpu@10103 {
 			compatible = "apple,firestorm";
 			device_type = "cpu";
 			reg = <0x0 0x10103>;
 			enable-method = "spin-table";
 			cpu-release-addr = <0 0>; /* To be filled by loader */
+			operating-points-v2 = <&pcluster_opp>;
+			capacity-dmips-mhz = <1024>;
+			apple,freq-domain = <&cpufreq_hw 1>;
+		};
+	};
+
+	ecluster_opp: opp-table-0 {
+		compatible = "operating-points-v2";
+		opp-shared;
+
+		opp01 {
+			opp-hz = /bits/ 64 <600000000>;
+			opp-level = <1>;
+			clock-latency-ns = <7500>;
+		};
+		opp02 {
+			opp-hz = /bits/ 64 <972000000>;
+			opp-level = <2>;
+			clock-latency-ns = <22000>;
+		};
+		opp03 {
+			opp-hz = /bits/ 64 <1332000000>;
+			opp-level = <3>;
+			clock-latency-ns = <27000>;
+		};
+		opp04 {
+			opp-hz = /bits/ 64 <1704000000>;
+			opp-level = <4>;
+			clock-latency-ns = <33000>;
+		};
+		opp05 {
+			opp-hz = /bits/ 64 <2064000000>;
+			opp-level = <5>;
+			clock-latency-ns = <50000>;
 		};
 	};
 
+	pcluster_opp: opp-table-1 {
+		compatible = "operating-points-v2";
+		opp-shared;
+
+		opp01 {
+			opp-hz = /bits/ 64 <600000000>;
+			opp-level = <1>;
+			clock-latency-ns = <8000>;
+		};
+		opp02 {
+			opp-hz = /bits/ 64 <828000000>;
+			opp-level = <2>;
+			clock-latency-ns = <19000>;
+		};
+		opp03 {
+			opp-hz = /bits/ 64 <1056000000>;
+			opp-level = <3>;
+			clock-latency-ns = <21000>;
+		};
+		opp04 {
+			opp-hz = /bits/ 64 <1284000000>;
+			opp-level = <4>;
+			clock-latency-ns = <23000>;
+		};
+		opp05 {
+			opp-hz = /bits/ 64 <1500000000>;
+			opp-level = <5>;
+			clock-latency-ns = <24000>;
+		};
+		opp06 {
+			opp-hz = /bits/ 64 <1728000000>;
+			opp-level = <6>;
+			clock-latency-ns = <29000>;
+		};
+		opp07 {
+			opp-hz = /bits/ 64 <1956000000>;
+			opp-level = <7>;
+			clock-latency-ns = <31000>;
+		};
+		opp08 {
+			opp-hz = /bits/ 64 <2184000000>;
+			opp-level = <8>;
+			clock-latency-ns = <34000>;
+		};
+		opp09 {
+			opp-hz = /bits/ 64 <2388000000>;
+			opp-level = <9>;
+			clock-latency-ns = <36000>;
+		};
+		opp10 {
+			opp-hz = /bits/ 64 <2592000000>;
+			opp-level = <10>;
+			clock-latency-ns = <51000>;
+		};
+		opp11 {
+			opp-hz = /bits/ 64 <2772000000>;
+			opp-level = <11>;
+			clock-latency-ns = <54000>;
+		};
+		opp12 {
+			opp-hz = /bits/ 64 <2988000000>;
+			opp-level = <12>;
+			clock-latency-ns = <55000>;
+		};
+#if 0
+		/* Not available until CPU deep sleep is implemented */
+		opp13 {
+			opp-hz = /bits/ 64 <3096000000>;
+			opp-level = <13>;
+			clock-latency-ns = <55000>;
+			turbo-mode;
+		};
+		opp14 {
+			opp-hz = /bits/ 64 <3144000000>;
+			opp-level = <14>;
+			clock-latency-ns = <56000>;
+			turbo-mode;
+		};
+		opp15 {
+			opp-hz = /bits/ 64 <3204000000>;
+			opp-level = <15>;
+			clock-latency-ns = <56000>;
+			turbo-mode;
+		};
+#endif
+	};
+
 	timer {
 		compatible = "arm,armv8-timer";
 		interrupt-parent = <&aic>;
@@ -124,6 +298,15 @@ soc {
 		ranges;
 		nonposted-mmio;
 
+		cpufreq_hw: cpufreq@210e20000 {
+			compatible = "apple,t8103-soc-cpufreq", "apple,soc-cpufreq";
+			reg = <0x2 0x10e20000 0 0x1000>,
+			      <0x2 0x11e20000 0 0x1000>;
+			reg-names = "cluster0", "cluster1";
+
+			#freq-domain-cells = <1>;
+		};
+
 		i2c0: i2c@235010000 {
 			compatible = "apple,t8103-i2c", "apple,i2c";
 			reg = <0x2 0x35010000 0x0 0x4000>;
@@ -229,12 +412,12 @@ aic: interrupt-controller@23b100000 {
 			affinities {
 				e-core-pmu-affinity {
 					apple,fiq-index = <AIC_CPU_PMU_E>;
-					cpus = <&cpu0 &cpu1 &cpu2 &cpu3>;
+					cpus = <&cpu_e0 &cpu_e1 &cpu_e2 &cpu_e3>;
 				};
 
 				p-core-pmu-affinity {
 					apple,fiq-index = <AIC_CPU_PMU_P>;
-					cpus = <&cpu4 &cpu5 &cpu6 &cpu7>;
+					cpus = <&cpu_p0 &cpu_p1 &cpu_p2 &cpu_p3>;
 				};
 			};
 		};
-- 
2.35.1

[PATCH v2 4/4] arm64: dts: apple: Add CPU topology & cpufreq nodes for t8103

[Hector Martin]

Add the missing CPU topology/capacity information and the cpufreq nodes,
so we can have CPU frequency scaling and the scheduler has the
information it needs to make the correct decisions.

Boost states are commented out, as they are not yet available (that
requires CPU deep sleep support, to be eventually done via PSCI).
The driver supports them fine; the hardware will just refuse to ever
go into them at this time, so don't expose them to users until that's
done.

Signed-off-by: Hector Martin <marcan@marcan.st>
---
 arch/arm64/boot/dts/apple/t8103.dtsi | 203 +++++++++++++++++++++++++--
 1 file changed, 193 insertions(+), 10 deletions(-)

diff --git a/arch/arm64/boot/dts/apple/t8103.dtsi b/arch/arm64/boot/dts/apple/t8103.dtsi
index 9f8f4145db88..3df126a5a7dd 100644
--- a/arch/arm64/boot/dts/apple/t8103.dtsi
+++ b/arch/arm64/boot/dts/apple/t8103.dtsi
@@ -22,71 +22,245 @@ cpus {
 		#address-cells = <2>;
 		#size-cells = <0>;
 
-		cpu0: cpu@0 {
+		cpu-map {
+			cluster0 {
+				core0 {
+					cpu = <&cpu_e0>;
+				};
+				core1 {
+					cpu = <&cpu_e1>;
+				};
+				core2 {
+					cpu = <&cpu_e2>;
+				};
+				core3 {
+					cpu = <&cpu_e3>;
+				};
+			};
+
+			cluster1 {
+				core0 {
+					cpu = <&cpu_p0>;
+				};
+				core1 {
+					cpu = <&cpu_p1>;
+				};
+				core2 {
+					cpu = <&cpu_p2>;
+				};
+				core3 {
+					cpu = <&cpu_p3>;
+				};
+			};
+		};
+
+		cpu_e0: cpu@0 {
 			compatible = "apple,icestorm";
 			device_type = "cpu";
 			reg = <0x0 0x0>;
 			enable-method = "spin-table";
 			cpu-release-addr = <0 0>; /* To be filled by loader */
+			operating-points-v2 = <&ecluster_opp>;
+			capacity-dmips-mhz = <714>;
+			apple,freq-domain = <&cpufreq_hw 0>;
 		};
 
-		cpu1: cpu@1 {
+		cpu_e1: cpu@1 {
 			compatible = "apple,icestorm";
 			device_type = "cpu";
 			reg = <0x0 0x1>;
 			enable-method = "spin-table";
 			cpu-release-addr = <0 0>; /* To be filled by loader */
+			operating-points-v2 = <&ecluster_opp>;
+			capacity-dmips-mhz = <714>;
+			apple,freq-domain = <&cpufreq_hw 0>;
 		};
 
-		cpu2: cpu@2 {
+		cpu_e2: cpu@2 {
 			compatible = "apple,icestorm";
 			device_type = "cpu";
 			reg = <0x0 0x2>;
 			enable-method = "spin-table";
 			cpu-release-addr = <0 0>; /* To be filled by loader */
+			operating-points-v2 = <&ecluster_opp>;
+			capacity-dmips-mhz = <714>;
+			apple,freq-domain = <&cpufreq_hw 0>;
 		};
 
-		cpu3: cpu@3 {
+		cpu_e3: cpu@3 {
 			compatible = "apple,icestorm";
 			device_type = "cpu";
 			reg = <0x0 0x3>;
 			enable-method = "spin-table";
 			cpu-release-addr = <0 0>; /* To be filled by loader */
+			operating-points-v2 = <&ecluster_opp>;
+			capacity-dmips-mhz = <714>;
+			apple,freq-domain = <&cpufreq_hw 0>;
 		};
 
-		cpu4: cpu@10100 {
+		cpu_p0: cpu@10100 {
 			compatible = "apple,firestorm";
 			device_type = "cpu";
 			reg = <0x0 0x10100>;
 			enable-method = "spin-table";
 			cpu-release-addr = <0 0>; /* To be filled by loader */
+			operating-points-v2 = <&pcluster_opp>;
+			capacity-dmips-mhz = <1024>;
+			apple,freq-domain = <&cpufreq_hw 1>;
 		};
 
-		cpu5: cpu@10101 {
+		cpu_p1: cpu@10101 {
 			compatible = "apple,firestorm";
 			device_type = "cpu";
 			reg = <0x0 0x10101>;
 			enable-method = "spin-table";
 			cpu-release-addr = <0 0>; /* To be filled by loader */
+			operating-points-v2 = <&pcluster_opp>;
+			capacity-dmips-mhz = <1024>;
+			apple,freq-domain = <&cpufreq_hw 1>;
 		};
 
-		cpu6: cpu@10102 {
+		cpu_p2: cpu@10102 {
 			compatible = "apple,firestorm";
 			device_type = "cpu";
 			reg = <0x0 0x10102>;
 			enable-method = "spin-table";
 			cpu-release-addr = <0 0>; /* To be filled by loader */
+			operating-points-v2 = <&pcluster_opp>;
+			capacity-dmips-mhz = <1024>;
+			apple,freq-domain = <&cpufreq_hw 1>;
 		};
 
-		cpu7: cpu@10103 {
+		cpu_p3: cpu@10103 {
 			compatible = "apple,firestorm";
 			device_type = "cpu";
 			reg = <0x0 0x10103>;
 			enable-method = "spin-table";
 			cpu-release-addr = <0 0>; /* To be filled by loader */
+			operating-points-v2 = <&pcluster_opp>;
+			capacity-dmips-mhz = <1024>;
+			apple,freq-domain = <&cpufreq_hw 1>;
+		};
+	};
+
+	ecluster_opp: opp-table-0 {
+		compatible = "operating-points-v2";
+		opp-shared;
+
+		opp01 {
+			opp-hz = /bits/ 64 <600000000>;
+			opp-level = <1>;
+			clock-latency-ns = <7500>;
+		};
+		opp02 {
+			opp-hz = /bits/ 64 <972000000>;
+			opp-level = <2>;
+			clock-latency-ns = <22000>;
+		};
+		opp03 {
+			opp-hz = /bits/ 64 <1332000000>;
+			opp-level = <3>;
+			clock-latency-ns = <27000>;
+		};
+		opp04 {
+			opp-hz = /bits/ 64 <1704000000>;
+			opp-level = <4>;
+			clock-latency-ns = <33000>;
+		};
+		opp05 {
+			opp-hz = /bits/ 64 <2064000000>;
+			opp-level = <5>;
+			clock-latency-ns = <50000>;
 		};
 	};
 
+	pcluster_opp: opp-table-1 {
+		compatible = "operating-points-v2";
+		opp-shared;
+
+		opp01 {
+			opp-hz = /bits/ 64 <600000000>;
+			opp-level = <1>;
+			clock-latency-ns = <8000>;
+		};
+		opp02 {
+			opp-hz = /bits/ 64 <828000000>;
+			opp-level = <2>;
+			clock-latency-ns = <19000>;
+		};
+		opp03 {
+			opp-hz = /bits/ 64 <1056000000>;
+			opp-level = <3>;
+			clock-latency-ns = <21000>;
+		};
+		opp04 {
+			opp-hz = /bits/ 64 <1284000000>;
+			opp-level = <4>;
+			clock-latency-ns = <23000>;
+		};
+		opp05 {
+			opp-hz = /bits/ 64 <1500000000>;
+			opp-level = <5>;
+			clock-latency-ns = <24000>;
+		};
+		opp06 {
+			opp-hz = /bits/ 64 <1728000000>;
+			opp-level = <6>;
+			clock-latency-ns = <29000>;
+		};
+		opp07 {
+			opp-hz = /bits/ 64 <1956000000>;
+			opp-level = <7>;
+			clock-latency-ns = <31000>;
+		};
+		opp08 {
+			opp-hz = /bits/ 64 <2184000000>;
+			opp-level = <8>;
+			clock-latency-ns = <34000>;
+		};
+		opp09 {
+			opp-hz = /bits/ 64 <2388000000>;
+			opp-level = <9>;
+			clock-latency-ns = <36000>;
+		};
+		opp10 {
+			opp-hz = /bits/ 64 <2592000000>;
+			opp-level = <10>;
+			clock-latency-ns = <51000>;
+		};
+		opp11 {
+			opp-hz = /bits/ 64 <2772000000>;
+			opp-level = <11>;
+			clock-latency-ns = <54000>;
+		};
+		opp12 {
+			opp-hz = /bits/ 64 <2988000000>;
+			opp-level = <12>;
+			clock-latency-ns = <55000>;
+		};
+#if 0
+		/* Not available until CPU deep sleep is implemented */
+		opp13 {
+			opp-hz = /bits/ 64 <3096000000>;
+			opp-level = <13>;
+			clock-latency-ns = <55000>;
+			turbo-mode;
+		};
+		opp14 {
+			opp-hz = /bits/ 64 <3144000000>;
+			opp-level = <14>;
+			clock-latency-ns = <56000>;
+			turbo-mode;
+		};
+		opp15 {
+			opp-hz = /bits/ 64 <3204000000>;
+			opp-level = <15>;
+			clock-latency-ns = <56000>;
+			turbo-mode;
+		};
+#endif
+	};
+
 	timer {
 		compatible = "arm,armv8-timer";
 		interrupt-parent = <&aic>;
@@ -124,6 +298,15 @@ soc {
 		ranges;
 		nonposted-mmio;
 
+		cpufreq_hw: cpufreq@210e20000 {
+			compatible = "apple,t8103-soc-cpufreq", "apple,soc-cpufreq";
+			reg = <0x2 0x10e20000 0 0x1000>,
+			      <0x2 0x11e20000 0 0x1000>;
+			reg-names = "cluster0", "cluster1";
+
+			#freq-domain-cells = <1>;
+		};
+
 		i2c0: i2c@235010000 {
 			compatible = "apple,t8103-i2c", "apple,i2c";
 			reg = <0x2 0x35010000 0x0 0x4000>;
@@ -229,12 +412,12 @@ aic: interrupt-controller@23b100000 {
 			affinities {
 				e-core-pmu-affinity {
 					apple,fiq-index = <AIC_CPU_PMU_E>;
-					cpus = <&cpu0 &cpu1 &cpu2 &cpu3>;
+					cpus = <&cpu_e0 &cpu_e1 &cpu_e2 &cpu_e3>;
 				};
 
 				p-core-pmu-affinity {
 					apple,fiq-index = <AIC_CPU_PMU_P>;
-					cpus = <&cpu4 &cpu5 &cpu6 &cpu7>;
+					cpus = <&cpu_p0 &cpu_p1 &cpu_p2 &cpu_p3>;
 				};
 			};
 		};
-- 
2.35.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 1/4] MAINTAINERS: Add entries for Apple SoC cpufreq driver

[Viresh Kumar]

On 04-05-22, 16:51, Hector Martin wrote:
> Splitting this commit, as usual, to facilitate merges via the SoC tree.
> 
> Signed-off-by: Hector Martin <marcan@marcan.st>
> ---
>  MAINTAINERS | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index edc96cdb85e8..39bfa478fe55 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1835,6 +1835,7 @@ T:	git https://github.com/AsahiLinux/linux.git
>  F:	Documentation/devicetree/bindings/arm/apple.yaml
>  F:	Documentation/devicetree/bindings/arm/apple/*
>  F:	Documentation/devicetree/bindings/clock/apple,nco.yaml
> +F:	Documentation/devicetree/bindings/cpufreq/apple,soc-cpufreq.yaml
>  F:	Documentation/devicetree/bindings/i2c/apple,i2c.yaml
>  F:	Documentation/devicetree/bindings/interrupt-controller/apple,*
>  F:	Documentation/devicetree/bindings/mailbox/apple,mailbox.yaml
> @@ -1844,6 +1845,7 @@ F:	Documentation/devicetree/bindings/power/apple*
>  F:	Documentation/devicetree/bindings/watchdog/apple,wdt.yaml
>  F:	arch/arm64/boot/dts/apple/
>  F:	drivers/clk/clk-apple-nco.c
> +F:	drivers/cpufreq/apple-soc-cpufreq.c
>  F:	drivers/i2c/busses/i2c-pasemi-core.c
>  F:	drivers/i2c/busses/i2c-pasemi-platform.c
>  F:	drivers/irqchip/irq-apple-aic.c

This should be the last patch instead, or should at least be added
after the files are merged first. If someone checks out at this
commit, the files won't be available but still linked here.

-- 
viresh

Re: [PATCH v2 1/4] MAINTAINERS: Add entries for Apple SoC cpufreq driver

[Viresh Kumar]

On 04-05-22, 16:51, Hector Martin wrote:
> Splitting this commit, as usual, to facilitate merges via the SoC tree.
> 
> Signed-off-by: Hector Martin <marcan@marcan.st>
> ---
>  MAINTAINERS | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index edc96cdb85e8..39bfa478fe55 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1835,6 +1835,7 @@ T:	git https://github.com/AsahiLinux/linux.git
>  F:	Documentation/devicetree/bindings/arm/apple.yaml
>  F:	Documentation/devicetree/bindings/arm/apple/*
>  F:	Documentation/devicetree/bindings/clock/apple,nco.yaml
> +F:	Documentation/devicetree/bindings/cpufreq/apple,soc-cpufreq.yaml
>  F:	Documentation/devicetree/bindings/i2c/apple,i2c.yaml
>  F:	Documentation/devicetree/bindings/interrupt-controller/apple,*
>  F:	Documentation/devicetree/bindings/mailbox/apple,mailbox.yaml
> @@ -1844,6 +1845,7 @@ F:	Documentation/devicetree/bindings/power/apple*
>  F:	Documentation/devicetree/bindings/watchdog/apple,wdt.yaml
>  F:	arch/arm64/boot/dts/apple/
>  F:	drivers/clk/clk-apple-nco.c
> +F:	drivers/cpufreq/apple-soc-cpufreq.c
>  F:	drivers/i2c/busses/i2c-pasemi-core.c
>  F:	drivers/i2c/busses/i2c-pasemi-platform.c
>  F:	drivers/irqchip/irq-apple-aic.c

This should be the last patch instead, or should at least be added
after the files are merged first. If someone checks out at this
commit, the files won't be available but still linked here.

-- 
viresh

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 0/4] Apple SoC cpufreq driver

[Viresh Kumar]

On 04-05-22, 16:51, Hector Martin wrote:
> Hi folks,
> 
> Here's a second take on the cpufreq driver for Apple SoCs. This is a
> complete rewrite using a stand-alone cpufreq driver instead of using the
> cpufreq-dt infrastructure.
> 
> Since v1 we ran some experiments on the memory controller performance
> switching and it turns out it doesn't make a huge difference, so it
> makes sense to punt that feature to the future (perhaps once a proper
> memory controller driver exists for other reasons, e.g. for error
> handling).
> 
> One advantage of having a standalone cpufreq driver is that we can
> support fast switching. This also means any future interaction with
> the memory controller will probably use some bespoke mechanism instead
> of the genpd infrastructure, so we can keep the fast path without
> allowing sleeps/etc.
> 
> The driver is based on scpi-cpufreq.c, with some bits (e.g. the
> apple,freq-domain stuff) inspired by how cpufreq-qcom-hw does it.
> I'm not sure if that particular property should be described
> in a binding, since it goes in the cpu nodes (qcom doesn't have it
> anywhere...).

Hi Mani,

I can see that Rob asked you to add this somewhere, maybe in arm/cpu
stuff, but I don't think you ever sent a patch with that. What
happened ?

https://lore.kernel.org/lkml/20201013171800.GA3716411@bogus/

-- 
viresh

Re: [PATCH v2 0/4] Apple SoC cpufreq driver

[Viresh Kumar]

On 04-05-22, 16:51, Hector Martin wrote:
> Hi folks,
> 
> Here's a second take on the cpufreq driver for Apple SoCs. This is a
> complete rewrite using a stand-alone cpufreq driver instead of using the
> cpufreq-dt infrastructure.
> 
> Since v1 we ran some experiments on the memory controller performance
> switching and it turns out it doesn't make a huge difference, so it
> makes sense to punt that feature to the future (perhaps once a proper
> memory controller driver exists for other reasons, e.g. for error
> handling).
> 
> One advantage of having a standalone cpufreq driver is that we can
> support fast switching. This also means any future interaction with
> the memory controller will probably use some bespoke mechanism instead
> of the genpd infrastructure, so we can keep the fast path without
> allowing sleeps/etc.
> 
> The driver is based on scpi-cpufreq.c, with some bits (e.g. the
> apple,freq-domain stuff) inspired by how cpufreq-qcom-hw does it.
> I'm not sure if that particular property should be described
> in a binding, since it goes in the cpu nodes (qcom doesn't have it
> anywhere...).

Hi Mani,

I can see that Rob asked you to add this somewhere, maybe in arm/cpu
stuff, but I don't think you ever sent a patch with that. What
happened ?

https://lore.kernel.org/lkml/20201013171800.GA3716411@bogus/

-- 
viresh

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 1/4] MAINTAINERS: Add entries for Apple SoC cpufreq driver

[Hector Martin]

On 04/05/2022 19.17, Viresh Kumar wrote:
> On 04-05-22, 16:51, Hector Martin wrote:
>> Splitting this commit, as usual, to facilitate merges via the SoC tree.
>>
>> Signed-off-by: Hector Martin <marcan@marcan.st>
>> ---
>>  MAINTAINERS | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index edc96cdb85e8..39bfa478fe55 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -1835,6 +1835,7 @@ T:	git https://github.com/AsahiLinux/linux.git
>>  F:	Documentation/devicetree/bindings/arm/apple.yaml
>>  F:	Documentation/devicetree/bindings/arm/apple/*
>>  F:	Documentation/devicetree/bindings/clock/apple,nco.yaml
>> +F:	Documentation/devicetree/bindings/cpufreq/apple,soc-cpufreq.yaml
>>  F:	Documentation/devicetree/bindings/i2c/apple,i2c.yaml
>>  F:	Documentation/devicetree/bindings/interrupt-controller/apple,*
>>  F:	Documentation/devicetree/bindings/mailbox/apple,mailbox.yaml
>> @@ -1844,6 +1845,7 @@ F:	Documentation/devicetree/bindings/power/apple*
>>  F:	Documentation/devicetree/bindings/watchdog/apple,wdt.yaml
>>  F:	arch/arm64/boot/dts/apple/
>>  F:	drivers/clk/clk-apple-nco.c
>> +F:	drivers/cpufreq/apple-soc-cpufreq.c
>>  F:	drivers/i2c/busses/i2c-pasemi-core.c
>>  F:	drivers/i2c/busses/i2c-pasemi-platform.c
>>  F:	drivers/irqchip/irq-apple-aic.c
> 
> This should be the last patch instead, or should at least be added
> after the files are merged first. If someone checks out at this
> commit, the files won't be available but still linked here.

Isn't that backwards? If someone touches the files, we want them to be
able to get_maintainer.pl, so the MAINTAINERS entries should come first.
It doesn't really cause any issues if there are entries that point at
files that don't exist yet, right?

Though this is mostly a moot point because the purpose of splitting this
out is so we can merge this one patch through the SoC tree, at which
point the ordering isn't guaranteed (unless the whole series goes
through SoC). It's a minor issue though; we've done it like this for
other series and it hasn't caused anyone trouble.

-- 
Hector Martin (marcan@marcan.st)
Public Key: https://mrcn.st/pub

Re: [PATCH v2 1/4] MAINTAINERS: Add entries for Apple SoC cpufreq driver

[Hector Martin]

On 04/05/2022 19.17, Viresh Kumar wrote:
> On 04-05-22, 16:51, Hector Martin wrote:
>> Splitting this commit, as usual, to facilitate merges via the SoC tree.
>>
>> Signed-off-by: Hector Martin <marcan@marcan.st>
>> ---
>>  MAINTAINERS | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index edc96cdb85e8..39bfa478fe55 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -1835,6 +1835,7 @@ T:	git https://github.com/AsahiLinux/linux.git
>>  F:	Documentation/devicetree/bindings/arm/apple.yaml
>>  F:	Documentation/devicetree/bindings/arm/apple/*
>>  F:	Documentation/devicetree/bindings/clock/apple,nco.yaml
>> +F:	Documentation/devicetree/bindings/cpufreq/apple,soc-cpufreq.yaml
>>  F:	Documentation/devicetree/bindings/i2c/apple,i2c.yaml
>>  F:	Documentation/devicetree/bindings/interrupt-controller/apple,*
>>  F:	Documentation/devicetree/bindings/mailbox/apple,mailbox.yaml
>> @@ -1844,6 +1845,7 @@ F:	Documentation/devicetree/bindings/power/apple*
>>  F:	Documentation/devicetree/bindings/watchdog/apple,wdt.yaml
>>  F:	arch/arm64/boot/dts/apple/
>>  F:	drivers/clk/clk-apple-nco.c
>> +F:	drivers/cpufreq/apple-soc-cpufreq.c
>>  F:	drivers/i2c/busses/i2c-pasemi-core.c
>>  F:	drivers/i2c/busses/i2c-pasemi-platform.c
>>  F:	drivers/irqchip/irq-apple-aic.c
> 
> This should be the last patch instead, or should at least be added
> after the files are merged first. If someone checks out at this
> commit, the files won't be available but still linked here.

Isn't that backwards? If someone touches the files, we want them to be
able to get_maintainer.pl, so the MAINTAINERS entries should come first.
It doesn't really cause any issues if there are entries that point at
files that don't exist yet, right?

Though this is mostly a moot point because the purpose of splitting this
out is so we can merge this one patch through the SoC tree, at which
point the ordering isn't guaranteed (unless the whole series goes
through SoC). It's a minor issue though; we've done it like this for
other series and it hasn't caused anyone trouble.

-- 
Hector Martin (marcan@marcan.st)
Public Key: https://mrcn.st/pub

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 0/4] Apple SoC cpufreq driver

[Manivannan Sadhasivam]

Hi Viresh,

On Wed, May 04, 2022 at 03:57:45PM +0530, Viresh Kumar wrote:
> On 04-05-22, 16:51, Hector Martin wrote:
> > Hi folks,
> > 
> > Here's a second take on the cpufreq driver for Apple SoCs. This is a
> > complete rewrite using a stand-alone cpufreq driver instead of using the
> > cpufreq-dt infrastructure.
> > 
> > Since v1 we ran some experiments on the memory controller performance
> > switching and it turns out it doesn't make a huge difference, so it
> > makes sense to punt that feature to the future (perhaps once a proper
> > memory controller driver exists for other reasons, e.g. for error
> > handling).
> > 
> > One advantage of having a standalone cpufreq driver is that we can
> > support fast switching. This also means any future interaction with
> > the memory controller will probably use some bespoke mechanism instead
> > of the genpd infrastructure, so we can keep the fast path without
> > allowing sleeps/etc.
> > 
> > The driver is based on scpi-cpufreq.c, with some bits (e.g. the
> > apple,freq-domain stuff) inspired by how cpufreq-qcom-hw does it.
> > I'm not sure if that particular property should be described
> > in a binding, since it goes in the cpu nodes (qcom doesn't have it
> > anywhere...).
> 
> Hi Mani,
> 
> I can see that Rob asked you to add this somewhere, maybe in arm/cpu
> stuff, but I don't think you ever sent a patch with that. What
> happened ?
> 
> https://lore.kernel.org/lkml/20201013171800.GA3716411@bogus/
> 

Oops. Looks like that one slipped through the cracks. I did add it to my todo
list for qcom-cpufreq but missed it completely.

I will look into it.

Thanks,
Mani

> -- 
> viresh

Re: [PATCH v2 0/4] Apple SoC cpufreq driver

[Manivannan Sadhasivam]

Hi Viresh,

On Wed, May 04, 2022 at 03:57:45PM +0530, Viresh Kumar wrote:
> On 04-05-22, 16:51, Hector Martin wrote:
> > Hi folks,
> > 
> > Here's a second take on the cpufreq driver for Apple SoCs. This is a
> > complete rewrite using a stand-alone cpufreq driver instead of using the
> > cpufreq-dt infrastructure.
> > 
> > Since v1 we ran some experiments on the memory controller performance
> > switching and it turns out it doesn't make a huge difference, so it
> > makes sense to punt that feature to the future (perhaps once a proper
> > memory controller driver exists for other reasons, e.g. for error
> > handling).
> > 
> > One advantage of having a standalone cpufreq driver is that we can
> > support fast switching. This also means any future interaction with
> > the memory controller will probably use some bespoke mechanism instead
> > of the genpd infrastructure, so we can keep the fast path without
> > allowing sleeps/etc.
> > 
> > The driver is based on scpi-cpufreq.c, with some bits (e.g. the
> > apple,freq-domain stuff) inspired by how cpufreq-qcom-hw does it.
> > I'm not sure if that particular property should be described
> > in a binding, since it goes in the cpu nodes (qcom doesn't have it
> > anywhere...).
> 
> Hi Mani,
> 
> I can see that Rob asked you to add this somewhere, maybe in arm/cpu
> stuff, but I don't think you ever sent a patch with that. What
> happened ?
> 
> https://lore.kernel.org/lkml/20201013171800.GA3716411@bogus/
> 

Oops. Looks like that one slipped through the cracks. I did add it to my todo
list for qcom-cpufreq but missed it completely.

I will look into it.

Thanks,
Mani

> -- 
> viresh

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 1/4] MAINTAINERS: Add entries for Apple SoC cpufreq driver

[Krzysztof Kozlowski]

On 04/05/2022 16:52, Hector Martin wrote:
> On 04/05/2022 19.17, Viresh Kumar wrote:
>> On 04-05-22, 16:51, Hector Martin wrote:
>>> Splitting this commit, as usual, to facilitate merges via the SoC tree.
>>>
>>> Signed-off-by: Hector Martin <marcan@marcan.st>
>>> ---
>>>  MAINTAINERS | 2 ++
>>>  1 file changed, 2 insertions(+)
>>>
>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>> index edc96cdb85e8..39bfa478fe55 100644
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -1835,6 +1835,7 @@ T:	git https://github.com/AsahiLinux/linux.git
>>>  F:	Documentation/devicetree/bindings/arm/apple.yaml
>>>  F:	Documentation/devicetree/bindings/arm/apple/*
>>>  F:	Documentation/devicetree/bindings/clock/apple,nco.yaml
>>> +F:	Documentation/devicetree/bindings/cpufreq/apple,soc-cpufreq.yaml
>>>  F:	Documentation/devicetree/bindings/i2c/apple,i2c.yaml
>>>  F:	Documentation/devicetree/bindings/interrupt-controller/apple,*
>>>  F:	Documentation/devicetree/bindings/mailbox/apple,mailbox.yaml
>>> @@ -1844,6 +1845,7 @@ F:	Documentation/devicetree/bindings/power/apple*
>>>  F:	Documentation/devicetree/bindings/watchdog/apple,wdt.yaml
>>>  F:	arch/arm64/boot/dts/apple/
>>>  F:	drivers/clk/clk-apple-nco.c
>>> +F:	drivers/cpufreq/apple-soc-cpufreq.c
>>>  F:	drivers/i2c/busses/i2c-pasemi-core.c
>>>  F:	drivers/i2c/busses/i2c-pasemi-platform.c
>>>  F:	drivers/irqchip/irq-apple-aic.c
>>
>> This should be the last patch instead, or should at least be added
>> after the files are merged first. If someone checks out at this
>> commit, the files won't be available but still linked here.
> 
> Isn't that backwards? 

No, because we have tools for checking valid paths (in some places), so
when using that tool, the history is not bisectable.

> If someone touches the files, we want them to be
> able to get_maintainer.pl, so the MAINTAINERS entries should come first.
> It doesn't really cause any issues if there are entries that point at
> files that don't exist yet, right?

It hurts any current or future tools checking for valid paths.

> 
> Though this is mostly a moot point because the purpose of splitting this
> out is so we can merge this one patch through the SoC tree, at which
> point the ordering isn't guaranteed (unless the whole series goes
> through SoC). 

Just add each path change to respective commit adding that file. It
should not be a separate commit, at first place.

Separate commits are for adding entire Maintainers entry.

Best regards,
Krzysztof

Re: [PATCH v2 1/4] MAINTAINERS: Add entries for Apple SoC cpufreq driver

[Krzysztof Kozlowski]

On 04/05/2022 16:52, Hector Martin wrote:
> On 04/05/2022 19.17, Viresh Kumar wrote:
>> On 04-05-22, 16:51, Hector Martin wrote:
>>> Splitting this commit, as usual, to facilitate merges via the SoC tree.
>>>
>>> Signed-off-by: Hector Martin <marcan@marcan.st>
>>> ---
>>>  MAINTAINERS | 2 ++
>>>  1 file changed, 2 insertions(+)
>>>
>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>> index edc96cdb85e8..39bfa478fe55 100644
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -1835,6 +1835,7 @@ T:	git https://github.com/AsahiLinux/linux.git
>>>  F:	Documentation/devicetree/bindings/arm/apple.yaml
>>>  F:	Documentation/devicetree/bindings/arm/apple/*
>>>  F:	Documentation/devicetree/bindings/clock/apple,nco.yaml
>>> +F:	Documentation/devicetree/bindings/cpufreq/apple,soc-cpufreq.yaml
>>>  F:	Documentation/devicetree/bindings/i2c/apple,i2c.yaml
>>>  F:	Documentation/devicetree/bindings/interrupt-controller/apple,*
>>>  F:	Documentation/devicetree/bindings/mailbox/apple,mailbox.yaml
>>> @@ -1844,6 +1845,7 @@ F:	Documentation/devicetree/bindings/power/apple*
>>>  F:	Documentation/devicetree/bindings/watchdog/apple,wdt.yaml
>>>  F:	arch/arm64/boot/dts/apple/
>>>  F:	drivers/clk/clk-apple-nco.c
>>> +F:	drivers/cpufreq/apple-soc-cpufreq.c
>>>  F:	drivers/i2c/busses/i2c-pasemi-core.c
>>>  F:	drivers/i2c/busses/i2c-pasemi-platform.c
>>>  F:	drivers/irqchip/irq-apple-aic.c
>>
>> This should be the last patch instead, or should at least be added
>> after the files are merged first. If someone checks out at this
>> commit, the files won't be available but still linked here.
> 
> Isn't that backwards? 

No, because we have tools for checking valid paths (in some places), so
when using that tool, the history is not bisectable.

> If someone touches the files, we want them to be
> able to get_maintainer.pl, so the MAINTAINERS entries should come first.
> It doesn't really cause any issues if there are entries that point at
> files that don't exist yet, right?

It hurts any current or future tools checking for valid paths.

> 
> Though this is mostly a moot point because the purpose of splitting this
> out is so we can merge this one patch through the SoC tree, at which
> point the ordering isn't guaranteed (unless the whole series goes
> through SoC). 

Just add each path change to respective commit adding that file. It
should not be a separate commit, at first place.

Separate commits are for adding entire Maintainers entry.

Best regards,
Krzysztof

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 2/4] dt-bindings: cpufreq: apple,soc-cpufreq: Add binding for Apple SoC cpufreq

[Krzysztof Kozlowski]

On 04/05/2022 09:51, Hector Martin wrote:
> This binding represents the cpufreq/DVFS hardware present in Apple SoCs.
> The hardware has an independent controller per CPU cluster, but we
> represent them as a single cpufreq node since there can only be one
> systemwide cpufreq device (and since in the future, interactions with
> memory controller performance states will also involve cooperation
> between multiple frequency domains).
> 
> Signed-off-by: Hector Martin <marcan@marcan.st>
> ---
>  .../bindings/cpufreq/apple,soc-cpufreq.yaml   | 121 ++++++++++++++++++
>  1 file changed, 121 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/cpufreq/apple,soc-cpufreq.yaml
> 
> diff --git a/Documentation/devicetree/bindings/cpufreq/apple,soc-cpufreq.yaml b/Documentation/devicetree/bindings/cpufreq/apple,soc-cpufreq.yaml
> new file mode 100644
> index 000000000000..f398c1bd5de5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/cpufreq/apple,soc-cpufreq.yaml
> @@ -0,0 +1,121 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/cpufreq/apple,soc-cpufreq.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Apple SoC cpufreq device
> +
> +maintainers:
> +  - Hector Martin <marcan@marcan.st>
> +
> +description: |
> +  Apple SoCs (e.g. M1) have a per-cpu-cluster DVFS controller that is part of
> +  the cluster management register block. This binding uses the standard
> +  operating-points-v2 table to define the CPU performance states, with the
> +  opp-level property specifying the hardware p-state index for that level.
> +
> +properties:
> +  compatible:
> +    items:
> +      - enum:
> +          - apple,t8103-soc-cpufreq
> +          - apple,t6000-soc-cpufreq
> +      - const: apple,soc-cpufreq
> +
> +  reg:
> +    minItems: 1
> +    maxItems: 6

Is the number of clusters fixed for t8103 and t6000? Are these
compatibles strictly related to some specific M1 SoC? If yes, then you
should have constraints in allOf:if:then.


Best regards,
Krzysztof

Re: [PATCH v2 2/4] dt-bindings: cpufreq: apple,soc-cpufreq: Add binding for Apple SoC cpufreq

[Krzysztof Kozlowski]

On 04/05/2022 09:51, Hector Martin wrote:
> This binding represents the cpufreq/DVFS hardware present in Apple SoCs.
> The hardware has an independent controller per CPU cluster, but we
> represent them as a single cpufreq node since there can only be one
> systemwide cpufreq device (and since in the future, interactions with
> memory controller performance states will also involve cooperation
> between multiple frequency domains).
> 
> Signed-off-by: Hector Martin <marcan@marcan.st>
> ---
>  .../bindings/cpufreq/apple,soc-cpufreq.yaml   | 121 ++++++++++++++++++
>  1 file changed, 121 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/cpufreq/apple,soc-cpufreq.yaml
> 
> diff --git a/Documentation/devicetree/bindings/cpufreq/apple,soc-cpufreq.yaml b/Documentation/devicetree/bindings/cpufreq/apple,soc-cpufreq.yaml
> new file mode 100644
> index 000000000000..f398c1bd5de5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/cpufreq/apple,soc-cpufreq.yaml
> @@ -0,0 +1,121 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/cpufreq/apple,soc-cpufreq.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Apple SoC cpufreq device
> +
> +maintainers:
> +  - Hector Martin <marcan@marcan.st>
> +
> +description: |
> +  Apple SoCs (e.g. M1) have a per-cpu-cluster DVFS controller that is part of
> +  the cluster management register block. This binding uses the standard
> +  operating-points-v2 table to define the CPU performance states, with the
> +  opp-level property specifying the hardware p-state index for that level.
> +
> +properties:
> +  compatible:
> +    items:
> +      - enum:
> +          - apple,t8103-soc-cpufreq
> +          - apple,t6000-soc-cpufreq
> +      - const: apple,soc-cpufreq
> +
> +  reg:
> +    minItems: 1
> +    maxItems: 6

Is the number of clusters fixed for t8103 and t6000? Are these
compatibles strictly related to some specific M1 SoC? If yes, then you
should have constraints in allOf:if:then.


Best regards,
Krzysztof

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 1/4] MAINTAINERS: Add entries for Apple SoC cpufreq driver

[Viresh Kumar]

On 05-05-22, 10:42, Krzysztof Kozlowski wrote:
> On 04/05/2022 16:52, Hector Martin wrote:
> > On 04/05/2022 19.17, Viresh Kumar wrote:
> >> This should be the last patch instead, or should at least be added
> >> after the files are merged first. If someone checks out at this
> >> commit, the files won't be available but still linked here.
> > 
> > Isn't that backwards? 
> 
> No, because we have tools for checking valid paths (in some places), so
> when using that tool, the history is not bisectable.
> 
> > If someone touches the files, we want them to be
> > able to get_maintainer.pl, so the MAINTAINERS entries should come first.
> > It doesn't really cause any issues if there are entries that point at
> > files that don't exist yet, right?
> 
> It hurts any current or future tools checking for valid paths.
> 
> > 
> > Though this is mostly a moot point because the purpose of splitting this
> > out is so we can merge this one patch through the SoC tree, at which
> > point the ordering isn't guaranteed (unless the whole series goes
> > through SoC). 
> 
> Just add each path change to respective commit adding that file. It
> should not be a separate commit, at first place.
> 
> Separate commits are for adding entire Maintainers entry.

And there is no need for this patch to go via SoC tree, we can handle
minor conflicts later on if required.

-- 
viresh

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 1/4] MAINTAINERS: Add entries for Apple SoC cpufreq driver

[Viresh Kumar]

On 05-05-22, 10:42, Krzysztof Kozlowski wrote:
> On 04/05/2022 16:52, Hector Martin wrote:
> > On 04/05/2022 19.17, Viresh Kumar wrote:
> >> This should be the last patch instead, or should at least be added
> >> after the files are merged first. If someone checks out at this
> >> commit, the files won't be available but still linked here.
> > 
> > Isn't that backwards? 
> 
> No, because we have tools for checking valid paths (in some places), so
> when using that tool, the history is not bisectable.
> 
> > If someone touches the files, we want them to be
> > able to get_maintainer.pl, so the MAINTAINERS entries should come first.
> > It doesn't really cause any issues if there are entries that point at
> > files that don't exist yet, right?
> 
> It hurts any current or future tools checking for valid paths.
> 
> > 
> > Though this is mostly a moot point because the purpose of splitting this
> > out is so we can merge this one patch through the SoC tree, at which
> > point the ordering isn't guaranteed (unless the whole series goes
> > through SoC). 
> 
> Just add each path change to respective commit adding that file. It
> should not be a separate commit, at first place.
> 
> Separate commits are for adding entire Maintainers entry.

And there is no need for this patch to go via SoC tree, we can handle
minor conflicts later on if required.

-- 
viresh

Re: [PATCH v2 2/4] dt-bindings: cpufreq: apple,soc-cpufreq: Add binding for Apple SoC cpufreq

[Hector Martin]

On 05/05/2022 17.43, Krzysztof Kozlowski wrote:
> On 04/05/2022 09:51, Hector Martin wrote:
>> This binding represents the cpufreq/DVFS hardware present in Apple SoCs.
>> The hardware has an independent controller per CPU cluster, but we
>> represent them as a single cpufreq node since there can only be one
>> systemwide cpufreq device (and since in the future, interactions with
>> memory controller performance states will also involve cooperation
>> between multiple frequency domains).
>>
>> Signed-off-by: Hector Martin <marcan@marcan.st>
>> ---
>>  .../bindings/cpufreq/apple,soc-cpufreq.yaml   | 121 ++++++++++++++++++
>>  1 file changed, 121 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/cpufreq/apple,soc-cpufreq.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/cpufreq/apple,soc-cpufreq.yaml b/Documentation/devicetree/bindings/cpufreq/apple,soc-cpufreq.yaml
>> new file mode 100644
>> index 000000000000..f398c1bd5de5
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/cpufreq/apple,soc-cpufreq.yaml
>> @@ -0,0 +1,121 @@
>> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/cpufreq/apple,soc-cpufreq.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Apple SoC cpufreq device
>> +
>> +maintainers:
>> +  - Hector Martin <marcan@marcan.st>
>> +
>> +description: |
>> +  Apple SoCs (e.g. M1) have a per-cpu-cluster DVFS controller that is part of
>> +  the cluster management register block. This binding uses the standard
>> +  operating-points-v2 table to define the CPU performance states, with the
>> +  opp-level property specifying the hardware p-state index for that level.
>> +
>> +properties:
>> +  compatible:
>> +    items:
>> +      - enum:
>> +          - apple,t8103-soc-cpufreq
>> +          - apple,t6000-soc-cpufreq
>> +      - const: apple,soc-cpufreq
>> +
>> +  reg:
>> +    minItems: 1
>> +    maxItems: 6
> 
> Is the number of clusters fixed for t8103 and t6000? Are these
> compatibles strictly related to some specific M1 SoC? If yes, then you
> should have constraints in allOf:if:then.

No, t6000 includes t6002 which is a 2-die version and has 6 clusters,
t6001 and t6000 have 3. t8103 always has 2, but it's conceivable that
compatible could be used for other chips within the same generation with
a different number.

The general idea for these compats is as a fallback in case we need to
quirk something for individual SoCs or start using registers which
changed for some reason, but right now they are not used. But I think
given how closely related t6000/t6001/t6002 are (t6002 is literally two
t6001 dies, and t6000 is almost identical to t6001 with a chunk
missing), I think spelling those out as 3 separate compatibles is
overkill. In general we treat those 3 SoCs as identical in terms of
compatibles, but the one-cpufreq-node limitation means t6002 does have
twice the clusters.

It's also conceivable that Apple could start releasing CPUs with entire
clusters fused off, so then our bootloader would have to start mutating
the reg entry to represent that.

I can add constraints to express some of this if you really want me to,
but I'm not sure it's that useful. The way I see it, the compatibles
really *mean* "this soc has t8103 clusters" or "this soc has t6000
clusters" and the number of clusters is arbitrary and the driver will
never care about that. Honestly I'd rather have separate cpufreq nodes
for each cluster, but nobody else does it like that and there's only one
driver instance, so that gets complicated...

-- 
Hector Martin (marcan@marcan.st)
Public Key: https://mrcn.st/pub

Re: [PATCH v2 2/4] dt-bindings: cpufreq: apple,soc-cpufreq: Add binding for Apple SoC cpufreq

[Hector Martin]

On 05/05/2022 17.43, Krzysztof Kozlowski wrote:
> On 04/05/2022 09:51, Hector Martin wrote:
>> This binding represents the cpufreq/DVFS hardware present in Apple SoCs.
>> The hardware has an independent controller per CPU cluster, but we
>> represent them as a single cpufreq node since there can only be one
>> systemwide cpufreq device (and since in the future, interactions with
>> memory controller performance states will also involve cooperation
>> between multiple frequency domains).
>>
>> Signed-off-by: Hector Martin <marcan@marcan.st>
>> ---
>>  .../bindings/cpufreq/apple,soc-cpufreq.yaml   | 121 ++++++++++++++++++
>>  1 file changed, 121 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/cpufreq/apple,soc-cpufreq.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/cpufreq/apple,soc-cpufreq.yaml b/Documentation/devicetree/bindings/cpufreq/apple,soc-cpufreq.yaml
>> new file mode 100644
>> index 000000000000..f398c1bd5de5
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/cpufreq/apple,soc-cpufreq.yaml
>> @@ -0,0 +1,121 @@
>> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/cpufreq/apple,soc-cpufreq.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Apple SoC cpufreq device
>> +
>> +maintainers:
>> +  - Hector Martin <marcan@marcan.st>
>> +
>> +description: |
>> +  Apple SoCs (e.g. M1) have a per-cpu-cluster DVFS controller that is part of
>> +  the cluster management register block. This binding uses the standard
>> +  operating-points-v2 table to define the CPU performance states, with the
>> +  opp-level property specifying the hardware p-state index for that level.
>> +
>> +properties:
>> +  compatible:
>> +    items:
>> +      - enum:
>> +          - apple,t8103-soc-cpufreq
>> +          - apple,t6000-soc-cpufreq
>> +      - const: apple,soc-cpufreq
>> +
>> +  reg:
>> +    minItems: 1
>> +    maxItems: 6
> 
> Is the number of clusters fixed for t8103 and t6000? Are these
> compatibles strictly related to some specific M1 SoC? If yes, then you
> should have constraints in allOf:if:then.

No, t6000 includes t6002 which is a 2-die version and has 6 clusters,
t6001 and t6000 have 3. t8103 always has 2, but it's conceivable that
compatible could be used for other chips within the same generation with
a different number.

The general idea for these compats is as a fallback in case we need to
quirk something for individual SoCs or start using registers which
changed for some reason, but right now they are not used. But I think
given how closely related t6000/t6001/t6002 are (t6002 is literally two
t6001 dies, and t6000 is almost identical to t6001 with a chunk
missing), I think spelling those out as 3 separate compatibles is
overkill. In general we treat those 3 SoCs as identical in terms of
compatibles, but the one-cpufreq-node limitation means t6002 does have
twice the clusters.

It's also conceivable that Apple could start releasing CPUs with entire
clusters fused off, so then our bootloader would have to start mutating
the reg entry to represent that.

I can add constraints to express some of this if you really want me to,
but I'm not sure it's that useful. The way I see it, the compatibles
really *mean* "this soc has t8103 clusters" or "this soc has t6000
clusters" and the number of clusters is arbitrary and the driver will
never care about that. Honestly I'd rather have separate cpufreq nodes
for each cluster, but nobody else does it like that and there's only one
driver instance, so that gets complicated...

-- 
Hector Martin (marcan@marcan.st)
Public Key: https://mrcn.st/pub

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 0/4] Apple SoC cpufreq driver

[Manivannan Sadhasivam]

On Wed, May 04, 2022 at 09:30:26PM +0530, Manivannan Sadhasivam wrote:
> Hi Viresh,
> 
> On Wed, May 04, 2022 at 03:57:45PM +0530, Viresh Kumar wrote:
> > On 04-05-22, 16:51, Hector Martin wrote:
> > > Hi folks,
> > > 
> > > Here's a second take on the cpufreq driver for Apple SoCs. This is a
> > > complete rewrite using a stand-alone cpufreq driver instead of using the
> > > cpufreq-dt infrastructure.
> > > 
> > > Since v1 we ran some experiments on the memory controller performance
> > > switching and it turns out it doesn't make a huge difference, so it
> > > makes sense to punt that feature to the future (perhaps once a proper
> > > memory controller driver exists for other reasons, e.g. for error
> > > handling).
> > > 
> > > One advantage of having a standalone cpufreq driver is that we can
> > > support fast switching. This also means any future interaction with
> > > the memory controller will probably use some bespoke mechanism instead
> > > of the genpd infrastructure, so we can keep the fast path without
> > > allowing sleeps/etc.
> > > 
> > > The driver is based on scpi-cpufreq.c, with some bits (e.g. the
> > > apple,freq-domain stuff) inspired by how cpufreq-qcom-hw does it.
> > > I'm not sure if that particular property should be described
> > > in a binding, since it goes in the cpu nodes (qcom doesn't have it
> > > anywhere...).
> > 
> > Hi Mani,
> > 
> > I can see that Rob asked you to add this somewhere, maybe in arm/cpu
> > stuff, but I don't think you ever sent a patch with that. What
> > happened ?
> > 
> > https://lore.kernel.org/lkml/20201013171800.GA3716411@bogus/
> > 
> 
> Oops. Looks like that one slipped through the cracks. I did add it to my todo
> list for qcom-cpufreq but missed it completely.
> 
> I will look into it.
> 

So I did send a patch for adding the qcom specific property [1], but Rob asked
for a common one and that's where it got lost.

But in the last revision [2], you've asked for converting the qcom cpufreq
driver to support the generic performance domains instead. For maintaining
compatibility with the old dts files, we need to support the qcom specific
property as well.

I will send a series for that.

Thanks,
Mani

[1] https://patchwork.kernel.org/project/linux-pm/patch/20201020153944.18047-1-manivannan.sadhasivam@linaro.org/#23718065
[2] https://patchwork.kernel.org/project/linux-pm/patch/20210701105730.322718-4-angelogioacchino.delregno@somainline.org/ 
> Thanks,
> Mani
> 
> > -- 
> > viresh

-- 
மணிவண்ணன் சதாசிவம்

Re: [PATCH v2 0/4] Apple SoC cpufreq driver

[Manivannan Sadhasivam]

On Wed, May 04, 2022 at 09:30:26PM +0530, Manivannan Sadhasivam wrote:
> Hi Viresh,
> 
> On Wed, May 04, 2022 at 03:57:45PM +0530, Viresh Kumar wrote:
> > On 04-05-22, 16:51, Hector Martin wrote:
> > > Hi folks,
> > > 
> > > Here's a second take on the cpufreq driver for Apple SoCs. This is a
> > > complete rewrite using a stand-alone cpufreq driver instead of using the
> > > cpufreq-dt infrastructure.
> > > 
> > > Since v1 we ran some experiments on the memory controller performance
> > > switching and it turns out it doesn't make a huge difference, so it
> > > makes sense to punt that feature to the future (perhaps once a proper
> > > memory controller driver exists for other reasons, e.g. for error
> > > handling).
> > > 
> > > One advantage of having a standalone cpufreq driver is that we can
> > > support fast switching. This also means any future interaction with
> > > the memory controller will probably use some bespoke mechanism instead
> > > of the genpd infrastructure, so we can keep the fast path without
> > > allowing sleeps/etc.
> > > 
> > > The driver is based on scpi-cpufreq.c, with some bits (e.g. the
> > > apple,freq-domain stuff) inspired by how cpufreq-qcom-hw does it.
> > > I'm not sure if that particular property should be described
> > > in a binding, since it goes in the cpu nodes (qcom doesn't have it
> > > anywhere...).
> > 
> > Hi Mani,
> > 
> > I can see that Rob asked you to add this somewhere, maybe in arm/cpu
> > stuff, but I don't think you ever sent a patch with that. What
> > happened ?
> > 
> > https://lore.kernel.org/lkml/20201013171800.GA3716411@bogus/
> > 
> 
> Oops. Looks like that one slipped through the cracks. I did add it to my todo
> list for qcom-cpufreq but missed it completely.
> 
> I will look into it.
> 

So I did send a patch for adding the qcom specific property [1], but Rob asked
for a common one and that's where it got lost.

But in the last revision [2], you've asked for converting the qcom cpufreq
driver to support the generic performance domains instead. For maintaining
compatibility with the old dts files, we need to support the qcom specific
property as well.

I will send a series for that.

Thanks,
Mani

[1] https://patchwork.kernel.org/project/linux-pm/patch/20201020153944.18047-1-manivannan.sadhasivam@linaro.org/#23718065
[2] https://patchwork.kernel.org/project/linux-pm/patch/20210701105730.322718-4-angelogioacchino.delregno@somainline.org/ 
> Thanks,
> Mani
> 
> > -- 
> > viresh

-- 
மணிவண்ணன் சதாசிவம்

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 2/4] dt-bindings: cpufreq: apple,soc-cpufreq: Add binding for Apple SoC cpufreq

[Rob Herring]

On Wed, May 04, 2022 at 04:51:51PM +0900, Hector Martin wrote:
> This binding represents the cpufreq/DVFS hardware present in Apple SoCs.
> The hardware has an independent controller per CPU cluster, but we
> represent them as a single cpufreq node since there can only be one
> systemwide cpufreq device (and since in the future, interactions with
> memory controller performance states will also involve cooperation
> between multiple frequency domains).
> 
> Signed-off-by: Hector Martin <marcan@marcan.st>
> ---
>  .../bindings/cpufreq/apple,soc-cpufreq.yaml   | 121 ++++++++++++++++++
>  1 file changed, 121 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/cpufreq/apple,soc-cpufreq.yaml
> 
> diff --git a/Documentation/devicetree/bindings/cpufreq/apple,soc-cpufreq.yaml b/Documentation/devicetree/bindings/cpufreq/apple,soc-cpufreq.yaml
> new file mode 100644
> index 000000000000..f398c1bd5de5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/cpufreq/apple,soc-cpufreq.yaml
> @@ -0,0 +1,121 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/cpufreq/apple,soc-cpufreq.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Apple SoC cpufreq device
> +
> +maintainers:
> +  - Hector Martin <marcan@marcan.st>
> +
> +description: |
> +  Apple SoCs (e.g. M1) have a per-cpu-cluster DVFS controller that is part of
> +  the cluster management register block. This binding uses the standard
> +  operating-points-v2 table to define the CPU performance states, with the
> +  opp-level property specifying the hardware p-state index for that level.
> +
> +properties:
> +  compatible:
> +    items:
> +      - enum:
> +          - apple,t8103-soc-cpufreq
> +          - apple,t6000-soc-cpufreq
> +      - const: apple,soc-cpufreq
> +
> +  reg:
> +    minItems: 1
> +    maxItems: 6
> +    description: One register region per CPU cluster DVFS controller
> +
> +  reg-names:
> +    minItems: 1
> +    items:
> +      - const: cluster0
> +      - const: cluster1
> +      - const: cluster2
> +      - const: cluster3
> +      - const: cluster4
> +      - const: cluster5
> +
> +  '#freq-domain-cells':
> +    const: 1

Copied QCom it seems. Use 'performance-domains' which is the common 
binding.

> +
> +required:
> +  - compatible
> +  - reg
> +  - reg-names
> +  - '#freq-domain-cells'
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    // This example shows a single CPU per domain and 2 domains,
> +    // with two p-states per domain.
> +    // Shipping hardware has 2-4 CPUs per domain and 2-6 domains.
> +    cpus {
> +      #address-cells = <2>;
> +      #size-cells = <0>;
> +
> +      cpu@0 {
> +        compatible = "apple,icestorm";
> +        device_type = "cpu";
> +        reg = <0x0 0x0>;
> +        operating-points-v2 = <&ecluster_opp>;
> +        apple,freq-domain = <&cpufreq_hw 0>;
> +      };
> +
> +      cpu@10100 {
> +        compatible = "apple,firestorm";
> +        device_type = "cpu";
> +        reg = <0x0 0x10100>;
> +        operating-points-v2 = <&pcluster_opp>;
> +        apple,freq-domain = <&cpufreq_hw 1>;
> +      };
> +    };
> +
> +    ecluster_opp: opp-table-0 {
> +      compatible = "operating-points-v2";
> +      opp-shared;
> +
> +      opp01 {
> +        opp-hz = /bits/ 64 <600000000>;
> +        opp-level = <1>;
> +        clock-latency-ns = <7500>;
> +      };
> +      opp02 {
> +        opp-hz = /bits/ 64 <972000000>;
> +        opp-level = <2>;
> +        clock-latency-ns = <22000>;
> +      };
> +    };
> +
> +    pcluster_opp: opp-table-1 {
> +      compatible = "operating-points-v2";
> +      opp-shared;
> +
> +      opp01 {
> +        opp-hz = /bits/ 64 <600000000>;
> +        opp-level = <1>;
> +        clock-latency-ns = <8000>;
> +      };
> +      opp02 {
> +        opp-hz = /bits/ 64 <828000000>;
> +        opp-level = <2>;
> +        clock-latency-ns = <19000>;
> +      };
> +    };
> +
> +    soc {
> +      #address-cells = <2>;
> +      #size-cells = <2>;
> +
> +      cpufreq_hw: cpufreq@210e20000 {
> +        compatible = "apple,t8103-soc-cpufreq", "apple,soc-cpufreq";
> +        reg = <0x2 0x10e20000 0 0x1000>,
> +              <0x2 0x11e20000 0 0x1000>;
> +        reg-names = "cluster0", "cluster1";
> +        #freq-domain-cells = <1>;
> +      };
> +    };
> -- 
> 2.35.1
> 
> 

Re: [PATCH v2 2/4] dt-bindings: cpufreq: apple,soc-cpufreq: Add binding for Apple SoC cpufreq

[Rob Herring]

On Wed, May 04, 2022 at 04:51:51PM +0900, Hector Martin wrote:
> This binding represents the cpufreq/DVFS hardware present in Apple SoCs.
> The hardware has an independent controller per CPU cluster, but we
> represent them as a single cpufreq node since there can only be one
> systemwide cpufreq device (and since in the future, interactions with
> memory controller performance states will also involve cooperation
> between multiple frequency domains).
> 
> Signed-off-by: Hector Martin <marcan@marcan.st>
> ---
>  .../bindings/cpufreq/apple,soc-cpufreq.yaml   | 121 ++++++++++++++++++
>  1 file changed, 121 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/cpufreq/apple,soc-cpufreq.yaml
> 
> diff --git a/Documentation/devicetree/bindings/cpufreq/apple,soc-cpufreq.yaml b/Documentation/devicetree/bindings/cpufreq/apple,soc-cpufreq.yaml
> new file mode 100644
> index 000000000000..f398c1bd5de5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/cpufreq/apple,soc-cpufreq.yaml
> @@ -0,0 +1,121 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/cpufreq/apple,soc-cpufreq.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Apple SoC cpufreq device
> +
> +maintainers:
> +  - Hector Martin <marcan@marcan.st>
> +
> +description: |
> +  Apple SoCs (e.g. M1) have a per-cpu-cluster DVFS controller that is part of
> +  the cluster management register block. This binding uses the standard
> +  operating-points-v2 table to define the CPU performance states, with the
> +  opp-level property specifying the hardware p-state index for that level.
> +
> +properties:
> +  compatible:
> +    items:
> +      - enum:
> +          - apple,t8103-soc-cpufreq
> +          - apple,t6000-soc-cpufreq
> +      - const: apple,soc-cpufreq
> +
> +  reg:
> +    minItems: 1
> +    maxItems: 6
> +    description: One register region per CPU cluster DVFS controller
> +
> +  reg-names:
> +    minItems: 1
> +    items:
> +      - const: cluster0
> +      - const: cluster1
> +      - const: cluster2
> +      - const: cluster3
> +      - const: cluster4
> +      - const: cluster5
> +
> +  '#freq-domain-cells':
> +    const: 1

Copied QCom it seems. Use 'performance-domains' which is the common 
binding.

> +
> +required:
> +  - compatible
> +  - reg
> +  - reg-names
> +  - '#freq-domain-cells'
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    // This example shows a single CPU per domain and 2 domains,
> +    // with two p-states per domain.
> +    // Shipping hardware has 2-4 CPUs per domain and 2-6 domains.
> +    cpus {
> +      #address-cells = <2>;
> +      #size-cells = <0>;
> +
> +      cpu@0 {
> +        compatible = "apple,icestorm";
> +        device_type = "cpu";
> +        reg = <0x0 0x0>;
> +        operating-points-v2 = <&ecluster_opp>;
> +        apple,freq-domain = <&cpufreq_hw 0>;
> +      };
> +
> +      cpu@10100 {
> +        compatible = "apple,firestorm";
> +        device_type = "cpu";
> +        reg = <0x0 0x10100>;
> +        operating-points-v2 = <&pcluster_opp>;
> +        apple,freq-domain = <&cpufreq_hw 1>;
> +      };
> +    };
> +
> +    ecluster_opp: opp-table-0 {
> +      compatible = "operating-points-v2";
> +      opp-shared;
> +
> +      opp01 {
> +        opp-hz = /bits/ 64 <600000000>;
> +        opp-level = <1>;
> +        clock-latency-ns = <7500>;
> +      };
> +      opp02 {
> +        opp-hz = /bits/ 64 <972000000>;
> +        opp-level = <2>;
> +        clock-latency-ns = <22000>;
> +      };
> +    };
> +
> +    pcluster_opp: opp-table-1 {
> +      compatible = "operating-points-v2";
> +      opp-shared;
> +
> +      opp01 {
> +        opp-hz = /bits/ 64 <600000000>;
> +        opp-level = <1>;
> +        clock-latency-ns = <8000>;
> +      };
> +      opp02 {
> +        opp-hz = /bits/ 64 <828000000>;
> +        opp-level = <2>;
> +        clock-latency-ns = <19000>;
> +      };
> +    };
> +
> +    soc {
> +      #address-cells = <2>;
> +      #size-cells = <2>;
> +
> +      cpufreq_hw: cpufreq@210e20000 {
> +        compatible = "apple,t8103-soc-cpufreq", "apple,soc-cpufreq";
> +        reg = <0x2 0x10e20000 0 0x1000>,
> +              <0x2 0x11e20000 0 0x1000>;
> +        reg-names = "cluster0", "cluster1";
> +        #freq-domain-cells = <1>;
> +      };
> +    };
> -- 
> 2.35.1
> 
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel