All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v2 0/3] cpufreq: Add imx-cpufreq-dt driver
@ 2019-05-02 22:44 ` Leonard Crestez
  0 siblings, 0 replies; 36+ messages in thread
From: Leonard Crestez @ 2019-05-02 22:44 UTC (permalink / raw)
  To: Viresh Kumar, Lucas Stach, Shawn Guo
  Cc: Aisheng Dong, Jacky Bai, Anson Huang, linux-pm,
	Rafael J. Wysocki, dl-linux-imx, kernel, Fabio Estevam,
	linux-arm-kernel, Abel Vesa

Right now in upstream imx8m cpufreq support just lists a common subset
of OPPs because the higher ones should only be attempted after checking
speed grading in fuses.

Add a small driver which checks speed grading from nvmem cells before
registering cpufreq-dt.

---

By default kconfig builds it as a module even though it's very small.
Couldn't find a way for MODULE_DEVICE_TABLE to match on root node compat
string and there was no other appropriate node so register the
imx-cpufreq-dt platfrom device directly from imx8 soc driver instead. I
checked module is probed by default and rmmod/modprobe again works.

It seems that cpufreq-dt insists on adding the opp and regulator itself
so can't actually call dev_pm_opp_of_add_table and then
dev_pm_opp_disable so implementation was switched to opp-supported-hw.
Maybe I'm confused by API quirks?

The market segment logic was dropped because I couldn't find any good
references in datasheets for why lower or intermediary OPPs should be
disabled on certain market segments. Using opp-supported-hw means that
adding this in the future would require changing flags inside DT instead
of code, that seems undesirable for DT compat reasons.

This could also be extended to mach-imx7d speed grading.

I never noticed anything wrong with going above the fused speed grading
however it's technically unsafe so the cpufreq parts should go in before
DT changes.

Other changes since v1:
 * Turn into a proper module
 * Support imx8mq
Link to v1 (RFC): https://patchwork.kernel.org/patch/10916769/

Leonard Crestez (3):
  cpufreq: Add imx-cpufreq-dt driver
  arm64: dts: imx8mm: Add cpu speed grading and all OPPs
  arm64: dts: imx8mq: Add cpu speed grading and all OPPs

 arch/arm64/boot/dts/freescale/imx8mm.dtsi | 23 +++++-
 arch/arm64/boot/dts/freescale/imx8mq.dtsi | 23 +++++-
 drivers/cpufreq/Kconfig.arm               | 10 +++
 drivers/cpufreq/Makefile                  |  1 +
 drivers/cpufreq/cpufreq-dt-platdev.c      |  3 +
 drivers/cpufreq/imx-cpufreq-dt.c          | 99 +++++++++++++++++++++++
 drivers/soc/imx/soc-imx8.c                |  3 +
 7 files changed, 160 insertions(+), 2 deletions(-)
 create mode 100644 drivers/cpufreq/imx-cpufreq-dt.c

-- 
2.17.1

^ permalink raw reply	[flat|nested] 36+ messages in thread

* [PATCH v2 0/3] cpufreq: Add imx-cpufreq-dt driver
@ 2019-05-02 22:44 ` Leonard Crestez
  0 siblings, 0 replies; 36+ messages in thread
From: Leonard Crestez @ 2019-05-02 22:44 UTC (permalink / raw)
  To: Viresh Kumar, Lucas Stach, Shawn Guo
  Cc: Rafael J. Wysocki, Anson Huang, Jacky Bai, Abel Vesa,
	Aisheng Dong, Fabio Estevam, linux-pm, kernel, dl-linux-imx,
	linux-arm-kernel

Right now in upstream imx8m cpufreq support just lists a common subset
of OPPs because the higher ones should only be attempted after checking
speed grading in fuses.

Add a small driver which checks speed grading from nvmem cells before
registering cpufreq-dt.

---

By default kconfig builds it as a module even though it's very small.
Couldn't find a way for MODULE_DEVICE_TABLE to match on root node compat
string and there was no other appropriate node so register the
imx-cpufreq-dt platfrom device directly from imx8 soc driver instead. I
checked module is probed by default and rmmod/modprobe again works.

It seems that cpufreq-dt insists on adding the opp and regulator itself
so can't actually call dev_pm_opp_of_add_table and then
dev_pm_opp_disable so implementation was switched to opp-supported-hw.
Maybe I'm confused by API quirks?

The market segment logic was dropped because I couldn't find any good
references in datasheets for why lower or intermediary OPPs should be
disabled on certain market segments. Using opp-supported-hw means that
adding this in the future would require changing flags inside DT instead
of code, that seems undesirable for DT compat reasons.

This could also be extended to mach-imx7d speed grading.

I never noticed anything wrong with going above the fused speed grading
however it's technically unsafe so the cpufreq parts should go in before
DT changes.

Other changes since v1:
 * Turn into a proper module
 * Support imx8mq
Link to v1 (RFC): https://patchwork.kernel.org/patch/10916769/

Leonard Crestez (3):
  cpufreq: Add imx-cpufreq-dt driver
  arm64: dts: imx8mm: Add cpu speed grading and all OPPs
  arm64: dts: imx8mq: Add cpu speed grading and all OPPs

 arch/arm64/boot/dts/freescale/imx8mm.dtsi | 23 +++++-
 arch/arm64/boot/dts/freescale/imx8mq.dtsi | 23 +++++-
 drivers/cpufreq/Kconfig.arm               | 10 +++
 drivers/cpufreq/Makefile                  |  1 +
 drivers/cpufreq/cpufreq-dt-platdev.c      |  3 +
 drivers/cpufreq/imx-cpufreq-dt.c          | 99 +++++++++++++++++++++++
 drivers/soc/imx/soc-imx8.c                |  3 +
 7 files changed, 160 insertions(+), 2 deletions(-)
 create mode 100644 drivers/cpufreq/imx-cpufreq-dt.c

-- 
2.17.1


^ permalink raw reply	[flat|nested] 36+ messages in thread

* [PATCH v2 0/3] cpufreq: Add imx-cpufreq-dt driver
@ 2019-05-02 22:44 ` Leonard Crestez
  0 siblings, 0 replies; 36+ messages in thread
From: Leonard Crestez @ 2019-05-02 22:44 UTC (permalink / raw)
  To: Viresh Kumar, Lucas Stach, Shawn Guo
  Cc: Aisheng Dong, Jacky Bai, Anson Huang, linux-pm,
	Rafael J. Wysocki, dl-linux-imx, kernel, Fabio Estevam,
	linux-arm-kernel, Abel Vesa

Right now in upstream imx8m cpufreq support just lists a common subset
of OPPs because the higher ones should only be attempted after checking
speed grading in fuses.

Add a small driver which checks speed grading from nvmem cells before
registering cpufreq-dt.

---

By default kconfig builds it as a module even though it's very small.
Couldn't find a way for MODULE_DEVICE_TABLE to match on root node compat
string and there was no other appropriate node so register the
imx-cpufreq-dt platfrom device directly from imx8 soc driver instead. I
checked module is probed by default and rmmod/modprobe again works.

It seems that cpufreq-dt insists on adding the opp and regulator itself
so can't actually call dev_pm_opp_of_add_table and then
dev_pm_opp_disable so implementation was switched to opp-supported-hw.
Maybe I'm confused by API quirks?

The market segment logic was dropped because I couldn't find any good
references in datasheets for why lower or intermediary OPPs should be
disabled on certain market segments. Using opp-supported-hw means that
adding this in the future would require changing flags inside DT instead
of code, that seems undesirable for DT compat reasons.

This could also be extended to mach-imx7d speed grading.

I never noticed anything wrong with going above the fused speed grading
however it's technically unsafe so the cpufreq parts should go in before
DT changes.

Other changes since v1:
 * Turn into a proper module
 * Support imx8mq
Link to v1 (RFC): https://patchwork.kernel.org/patch/10916769/

Leonard Crestez (3):
  cpufreq: Add imx-cpufreq-dt driver
  arm64: dts: imx8mm: Add cpu speed grading and all OPPs
  arm64: dts: imx8mq: Add cpu speed grading and all OPPs

 arch/arm64/boot/dts/freescale/imx8mm.dtsi | 23 +++++-
 arch/arm64/boot/dts/freescale/imx8mq.dtsi | 23 +++++-
 drivers/cpufreq/Kconfig.arm               | 10 +++
 drivers/cpufreq/Makefile                  |  1 +
 drivers/cpufreq/cpufreq-dt-platdev.c      |  3 +
 drivers/cpufreq/imx-cpufreq-dt.c          | 99 +++++++++++++++++++++++
 drivers/soc/imx/soc-imx8.c                |  3 +
 7 files changed, 160 insertions(+), 2 deletions(-)
 create mode 100644 drivers/cpufreq/imx-cpufreq-dt.c

-- 
2.17.1

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

^ permalink raw reply	[flat|nested] 36+ messages in thread

* [PATCH v2 1/3] cpufreq: Add imx-cpufreq-dt driver
@ 2019-05-02 22:44   ` Leonard Crestez
  0 siblings, 0 replies; 36+ messages in thread
From: Leonard Crestez @ 2019-05-02 22:44 UTC (permalink / raw)
  To: Viresh Kumar, Lucas Stach, Shawn Guo
  Cc: Aisheng Dong, Jacky Bai, Anson Huang, linux-pm,
	Rafael J. Wysocki, dl-linux-imx, kernel, Fabio Estevam,
	linux-arm-kernel, Abel Vesa

Right now in upstream imx8m cpufreq support just lists a common subset
of OPPs because the higher ones should only be attempted after checking
speed grading in fuses.

Add a small driver which checks speed grading from nvmem cells before
registering cpufreq-dt.

This allows unlocking all frequencies for imx8mm and imx8mq.

Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>

---
 drivers/cpufreq/Kconfig.arm          | 10 +++
 drivers/cpufreq/Makefile             |  1 +
 drivers/cpufreq/cpufreq-dt-platdev.c |  3 +
 drivers/cpufreq/imx-cpufreq-dt.c     | 99 ++++++++++++++++++++++++++++
 drivers/soc/imx/soc-imx8.c           |  3 +
 5 files changed, 116 insertions(+)
 create mode 100644 drivers/cpufreq/imx-cpufreq-dt.c

diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 179a1d302f48..f8e40429e290 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -90,10 +90,20 @@ config ARM_IMX6Q_CPUFREQ
 	help
 	  This adds cpufreq driver support for Freescale i.MX6 series SoCs.
 
 	  If in doubt, say N.
 
+config ARM_IMX_CPUFREQ_DT
+	tristate "Freescale i.MX8M cpufreq support"
+	depends on ARCH_MXC && CPUFREQ_DT
+	default m if (ARCH_MXC && CPUFREQ_DT)
+	help
+	  This adds cpufreq driver support for newer Freescale i.MX series
+	  SoCs, based on cpufreq-dt
+
+	  If in doubt, say N.
+
 config ARM_KIRKWOOD_CPUFREQ
 	def_bool MACH_KIRKWOOD
 	help
 	  This adds the CPUFreq driver for Marvell Kirkwood
 	  SoCs.
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 689b26c6f949..7bcda2273d0c 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -54,10 +54,11 @@ obj-$(CONFIG_ARM_ARMADA_8K_CPUFREQ)	+= armada-8k-cpufreq.o
 obj-$(CONFIG_ARM_BRCMSTB_AVS_CPUFREQ)	+= brcmstb-avs-cpufreq.o
 obj-$(CONFIG_ACPI_CPPC_CPUFREQ)		+= cppc_cpufreq.o
 obj-$(CONFIG_ARCH_DAVINCI)		+= davinci-cpufreq.o
 obj-$(CONFIG_ARM_HIGHBANK_CPUFREQ)	+= highbank-cpufreq.o
 obj-$(CONFIG_ARM_IMX6Q_CPUFREQ)		+= imx6q-cpufreq.o
+obj-$(CONFIG_ARM_IMX_CPUFREQ_DT)	+= imx-cpufreq-dt.o
 obj-$(CONFIG_ARM_KIRKWOOD_CPUFREQ)	+= kirkwood-cpufreq.o
 obj-$(CONFIG_ARM_MEDIATEK_CPUFREQ)	+= mediatek-cpufreq.o
 obj-$(CONFIG_MACH_MVEBU_V7)		+= mvebu-cpufreq.o
 obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ)	+= omap-cpufreq.o
 obj-$(CONFIG_ARM_PXA2xx_CPUFREQ)	+= pxa2xx-cpufreq.o
diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
index 47729a22c159..19c1aad57e26 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -106,10 +106,13 @@ static const struct of_device_id whitelist[] __initconst = {
  */
 static const struct of_device_id blacklist[] __initconst = {
 	{ .compatible = "calxeda,highbank", },
 	{ .compatible = "calxeda,ecx-2000", },
 
+	{ .compatible = "fsl,imx8mq", },
+	{ .compatible = "fsl,imx8mm", },
+
 	{ .compatible = "marvell,armadaxp", },
 
 	{ .compatible = "mediatek,mt2701", },
 	{ .compatible = "mediatek,mt2712", },
 	{ .compatible = "mediatek,mt7622", },
diff --git a/drivers/cpufreq/imx-cpufreq-dt.c b/drivers/cpufreq/imx-cpufreq-dt.c
new file mode 100644
index 000000000000..9b2ee96c9213
--- /dev/null
+++ b/drivers/cpufreq/imx-cpufreq-dt.c
@@ -0,0 +1,99 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2019 NXP
+ */
+
+#include <linux/cpu.h>
+#include <linux/err.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/nvmem-consumer.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/pm_opp.h>
+#include <linux/slab.h>
+
+#define OCOTP_CFG3_SPEED_GRADE_SHIFT	8
+#define OCOTP_CFG3_SPEED_GRADE_MASK	(0x3 << 8)
+
+static const struct of_device_id imx_cpufreq_dt_match_list[] = {
+	{ .compatible = "fsl,imx8mm" },
+	{ .compatible = "fsl,imx8mq" },
+	{}
+};
+
+static const struct of_device_id *imx_cpufreq_dt_match_node(void)
+{
+	struct device_node *np;
+	const struct of_device_id *match;
+
+	np = of_find_node_by_path("/");
+	match = of_match_node(imx_cpufreq_dt_match_list, np);
+	of_node_put(np);
+
+	return match;
+}
+
+/* cpufreq-dt device registered by imx-cpufreq-dt */
+static struct platform_device *cpufreq_dt_pdev;
+static struct opp_table *cpufreq_opp_table;
+
+static int imx_cpufreq_dt_probe(struct platform_device *pdev)
+{
+	struct device *cpu_dev = get_cpu_device(0);
+	const struct of_device_id *match;
+	u32 speed_grade;
+	int ret;
+
+	match = imx_cpufreq_dt_match_node();
+	if (!match)
+		return -ENODEV;
+
+	ret = nvmem_cell_read_u32(cpu_dev, "speed_grade", &speed_grade);
+	if (ret)
+		return ret;
+
+	speed_grade = (speed_grade & OCOTP_CFG3_SPEED_GRADE_MASK) >> OCOTP_CFG3_SPEED_GRADE_SHIFT;
+	dev_info(&pdev->dev, "cpu speed grade %d\n", speed_grade);
+	speed_grade = 1 << speed_grade;
+
+	cpufreq_opp_table = dev_pm_opp_set_supported_hw(cpu_dev, &speed_grade, 1);
+	if (IS_ERR(cpufreq_opp_table)) {
+		ret = PTR_ERR(cpufreq_opp_table);
+		dev_err(&pdev->dev, "Failed to set supported opp: %d\n", ret);
+		return ret;
+	}
+
+	cpufreq_dt_pdev = platform_device_register_data(
+			&pdev->dev, "cpufreq-dt", -1, NULL, 0);
+	if (IS_ERR(cpufreq_dt_pdev)) {
+		dev_pm_opp_put_supported_hw(cpufreq_opp_table);
+		ret = PTR_ERR(cpufreq_dt_pdev);
+		dev_err(&pdev->dev, "Failed to register cpufreq-dt: %d\n", ret);
+		return ret;
+	}
+
+	return 0;
+}
+
+static int imx_cpufreq_dt_remove(struct platform_device *pdev)
+{
+	platform_device_unregister(cpufreq_dt_pdev);
+	dev_pm_opp_put_supported_hw(cpufreq_opp_table);
+
+	return 0;
+}
+
+static struct platform_driver imx_cpufreq_dt_driver = {
+	.probe = imx_cpufreq_dt_probe,
+	.remove = imx_cpufreq_dt_remove,
+	.driver = {
+		.name = "imx-cpufreq-dt",
+	},
+};
+module_platform_driver(imx_cpufreq_dt_driver);
+
+MODULE_ALIAS("platform:imx-cpufreq-dt");
+MODULE_DESCRIPTION("Freescale i.MX cpufreq speed grading driver");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/soc/imx/soc-imx8.c b/drivers/soc/imx/soc-imx8.c
index cd10726e64e4..02988bdfbb73 100644
--- a/drivers/soc/imx/soc-imx8.c
+++ b/drivers/soc/imx/soc-imx8.c
@@ -130,10 +130,13 @@ static int __init imx8_soc_init(void)
 
 	soc_dev = soc_device_register(soc_dev_attr);
 	if (IS_ERR(soc_dev))
 		goto free_rev;
 
+	if (IS_ENABLED(CONFIG_ARM_IMX_CPUFREQ_DT))
+		platform_device_register_simple("imx-cpufreq-dt", -1, NULL, 0);
+
 	return 0;
 
 free_rev:
 	kfree(soc_dev_attr->revision);
 free_soc:
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 36+ messages in thread

* [PATCH v2 1/3] cpufreq: Add imx-cpufreq-dt driver
@ 2019-05-02 22:44   ` Leonard Crestez
  0 siblings, 0 replies; 36+ messages in thread
From: Leonard Crestez @ 2019-05-02 22:44 UTC (permalink / raw)
  To: Viresh Kumar, Lucas Stach, Shawn Guo
  Cc: Rafael J. Wysocki, Anson Huang, Jacky Bai, Abel Vesa,
	Aisheng Dong, Fabio Estevam, linux-pm, kernel, dl-linux-imx,
	linux-arm-kernel

Right now in upstream imx8m cpufreq support just lists a common subset
of OPPs because the higher ones should only be attempted after checking
speed grading in fuses.

Add a small driver which checks speed grading from nvmem cells before
registering cpufreq-dt.

This allows unlocking all frequencies for imx8mm and imx8mq.

Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>

---
 drivers/cpufreq/Kconfig.arm          | 10 +++
 drivers/cpufreq/Makefile             |  1 +
 drivers/cpufreq/cpufreq-dt-platdev.c |  3 +
 drivers/cpufreq/imx-cpufreq-dt.c     | 99 ++++++++++++++++++++++++++++
 drivers/soc/imx/soc-imx8.c           |  3 +
 5 files changed, 116 insertions(+)
 create mode 100644 drivers/cpufreq/imx-cpufreq-dt.c

diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 179a1d302f48..f8e40429e290 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -90,10 +90,20 @@ config ARM_IMX6Q_CPUFREQ
 	help
 	  This adds cpufreq driver support for Freescale i.MX6 series SoCs.
 
 	  If in doubt, say N.
 
+config ARM_IMX_CPUFREQ_DT
+	tristate "Freescale i.MX8M cpufreq support"
+	depends on ARCH_MXC && CPUFREQ_DT
+	default m if (ARCH_MXC && CPUFREQ_DT)
+	help
+	  This adds cpufreq driver support for newer Freescale i.MX series
+	  SoCs, based on cpufreq-dt
+
+	  If in doubt, say N.
+
 config ARM_KIRKWOOD_CPUFREQ
 	def_bool MACH_KIRKWOOD
 	help
 	  This adds the CPUFreq driver for Marvell Kirkwood
 	  SoCs.
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 689b26c6f949..7bcda2273d0c 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -54,10 +54,11 @@ obj-$(CONFIG_ARM_ARMADA_8K_CPUFREQ)	+= armada-8k-cpufreq.o
 obj-$(CONFIG_ARM_BRCMSTB_AVS_CPUFREQ)	+= brcmstb-avs-cpufreq.o
 obj-$(CONFIG_ACPI_CPPC_CPUFREQ)		+= cppc_cpufreq.o
 obj-$(CONFIG_ARCH_DAVINCI)		+= davinci-cpufreq.o
 obj-$(CONFIG_ARM_HIGHBANK_CPUFREQ)	+= highbank-cpufreq.o
 obj-$(CONFIG_ARM_IMX6Q_CPUFREQ)		+= imx6q-cpufreq.o
+obj-$(CONFIG_ARM_IMX_CPUFREQ_DT)	+= imx-cpufreq-dt.o
 obj-$(CONFIG_ARM_KIRKWOOD_CPUFREQ)	+= kirkwood-cpufreq.o
 obj-$(CONFIG_ARM_MEDIATEK_CPUFREQ)	+= mediatek-cpufreq.o
 obj-$(CONFIG_MACH_MVEBU_V7)		+= mvebu-cpufreq.o
 obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ)	+= omap-cpufreq.o
 obj-$(CONFIG_ARM_PXA2xx_CPUFREQ)	+= pxa2xx-cpufreq.o
diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
index 47729a22c159..19c1aad57e26 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -106,10 +106,13 @@ static const struct of_device_id whitelist[] __initconst = {
  */
 static const struct of_device_id blacklist[] __initconst = {
 	{ .compatible = "calxeda,highbank", },
 	{ .compatible = "calxeda,ecx-2000", },
 
+	{ .compatible = "fsl,imx8mq", },
+	{ .compatible = "fsl,imx8mm", },
+
 	{ .compatible = "marvell,armadaxp", },
 
 	{ .compatible = "mediatek,mt2701", },
 	{ .compatible = "mediatek,mt2712", },
 	{ .compatible = "mediatek,mt7622", },
diff --git a/drivers/cpufreq/imx-cpufreq-dt.c b/drivers/cpufreq/imx-cpufreq-dt.c
new file mode 100644
index 000000000000..9b2ee96c9213
--- /dev/null
+++ b/drivers/cpufreq/imx-cpufreq-dt.c
@@ -0,0 +1,99 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2019 NXP
+ */
+
+#include <linux/cpu.h>
+#include <linux/err.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/nvmem-consumer.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/pm_opp.h>
+#include <linux/slab.h>
+
+#define OCOTP_CFG3_SPEED_GRADE_SHIFT	8
+#define OCOTP_CFG3_SPEED_GRADE_MASK	(0x3 << 8)
+
+static const struct of_device_id imx_cpufreq_dt_match_list[] = {
+	{ .compatible = "fsl,imx8mm" },
+	{ .compatible = "fsl,imx8mq" },
+	{}
+};
+
+static const struct of_device_id *imx_cpufreq_dt_match_node(void)
+{
+	struct device_node *np;
+	const struct of_device_id *match;
+
+	np = of_find_node_by_path("/");
+	match = of_match_node(imx_cpufreq_dt_match_list, np);
+	of_node_put(np);
+
+	return match;
+}
+
+/* cpufreq-dt device registered by imx-cpufreq-dt */
+static struct platform_device *cpufreq_dt_pdev;
+static struct opp_table *cpufreq_opp_table;
+
+static int imx_cpufreq_dt_probe(struct platform_device *pdev)
+{
+	struct device *cpu_dev = get_cpu_device(0);
+	const struct of_device_id *match;
+	u32 speed_grade;
+	int ret;
+
+	match = imx_cpufreq_dt_match_node();
+	if (!match)
+		return -ENODEV;
+
+	ret = nvmem_cell_read_u32(cpu_dev, "speed_grade", &speed_grade);
+	if (ret)
+		return ret;
+
+	speed_grade = (speed_grade & OCOTP_CFG3_SPEED_GRADE_MASK) >> OCOTP_CFG3_SPEED_GRADE_SHIFT;
+	dev_info(&pdev->dev, "cpu speed grade %d\n", speed_grade);
+	speed_grade = 1 << speed_grade;
+
+	cpufreq_opp_table = dev_pm_opp_set_supported_hw(cpu_dev, &speed_grade, 1);
+	if (IS_ERR(cpufreq_opp_table)) {
+		ret = PTR_ERR(cpufreq_opp_table);
+		dev_err(&pdev->dev, "Failed to set supported opp: %d\n", ret);
+		return ret;
+	}
+
+	cpufreq_dt_pdev = platform_device_register_data(
+			&pdev->dev, "cpufreq-dt", -1, NULL, 0);
+	if (IS_ERR(cpufreq_dt_pdev)) {
+		dev_pm_opp_put_supported_hw(cpufreq_opp_table);
+		ret = PTR_ERR(cpufreq_dt_pdev);
+		dev_err(&pdev->dev, "Failed to register cpufreq-dt: %d\n", ret);
+		return ret;
+	}
+
+	return 0;
+}
+
+static int imx_cpufreq_dt_remove(struct platform_device *pdev)
+{
+	platform_device_unregister(cpufreq_dt_pdev);
+	dev_pm_opp_put_supported_hw(cpufreq_opp_table);
+
+	return 0;
+}
+
+static struct platform_driver imx_cpufreq_dt_driver = {
+	.probe = imx_cpufreq_dt_probe,
+	.remove = imx_cpufreq_dt_remove,
+	.driver = {
+		.name = "imx-cpufreq-dt",
+	},
+};
+module_platform_driver(imx_cpufreq_dt_driver);
+
+MODULE_ALIAS("platform:imx-cpufreq-dt");
+MODULE_DESCRIPTION("Freescale i.MX cpufreq speed grading driver");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/soc/imx/soc-imx8.c b/drivers/soc/imx/soc-imx8.c
index cd10726e64e4..02988bdfbb73 100644
--- a/drivers/soc/imx/soc-imx8.c
+++ b/drivers/soc/imx/soc-imx8.c
@@ -130,10 +130,13 @@ static int __init imx8_soc_init(void)
 
 	soc_dev = soc_device_register(soc_dev_attr);
 	if (IS_ERR(soc_dev))
 		goto free_rev;
 
+	if (IS_ENABLED(CONFIG_ARM_IMX_CPUFREQ_DT))
+		platform_device_register_simple("imx-cpufreq-dt", -1, NULL, 0);
+
 	return 0;
 
 free_rev:
 	kfree(soc_dev_attr->revision);
 free_soc:
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 36+ messages in thread

* [PATCH v2 1/3] cpufreq: Add imx-cpufreq-dt driver
@ 2019-05-02 22:44   ` Leonard Crestez
  0 siblings, 0 replies; 36+ messages in thread
From: Leonard Crestez @ 2019-05-02 22:44 UTC (permalink / raw)
  To: Viresh Kumar, Lucas Stach, Shawn Guo
  Cc: Aisheng Dong, Jacky Bai, Anson Huang, linux-pm,
	Rafael J. Wysocki, dl-linux-imx, kernel, Fabio Estevam,
	linux-arm-kernel, Abel Vesa

Right now in upstream imx8m cpufreq support just lists a common subset
of OPPs because the higher ones should only be attempted after checking
speed grading in fuses.

Add a small driver which checks speed grading from nvmem cells before
registering cpufreq-dt.

This allows unlocking all frequencies for imx8mm and imx8mq.

Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>

---
 drivers/cpufreq/Kconfig.arm          | 10 +++
 drivers/cpufreq/Makefile             |  1 +
 drivers/cpufreq/cpufreq-dt-platdev.c |  3 +
 drivers/cpufreq/imx-cpufreq-dt.c     | 99 ++++++++++++++++++++++++++++
 drivers/soc/imx/soc-imx8.c           |  3 +
 5 files changed, 116 insertions(+)
 create mode 100644 drivers/cpufreq/imx-cpufreq-dt.c

diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 179a1d302f48..f8e40429e290 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -90,10 +90,20 @@ config ARM_IMX6Q_CPUFREQ
 	help
 	  This adds cpufreq driver support for Freescale i.MX6 series SoCs.
 
 	  If in doubt, say N.
 
+config ARM_IMX_CPUFREQ_DT
+	tristate "Freescale i.MX8M cpufreq support"
+	depends on ARCH_MXC && CPUFREQ_DT
+	default m if (ARCH_MXC && CPUFREQ_DT)
+	help
+	  This adds cpufreq driver support for newer Freescale i.MX series
+	  SoCs, based on cpufreq-dt
+
+	  If in doubt, say N.
+
 config ARM_KIRKWOOD_CPUFREQ
 	def_bool MACH_KIRKWOOD
 	help
 	  This adds the CPUFreq driver for Marvell Kirkwood
 	  SoCs.
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 689b26c6f949..7bcda2273d0c 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -54,10 +54,11 @@ obj-$(CONFIG_ARM_ARMADA_8K_CPUFREQ)	+= armada-8k-cpufreq.o
 obj-$(CONFIG_ARM_BRCMSTB_AVS_CPUFREQ)	+= brcmstb-avs-cpufreq.o
 obj-$(CONFIG_ACPI_CPPC_CPUFREQ)		+= cppc_cpufreq.o
 obj-$(CONFIG_ARCH_DAVINCI)		+= davinci-cpufreq.o
 obj-$(CONFIG_ARM_HIGHBANK_CPUFREQ)	+= highbank-cpufreq.o
 obj-$(CONFIG_ARM_IMX6Q_CPUFREQ)		+= imx6q-cpufreq.o
+obj-$(CONFIG_ARM_IMX_CPUFREQ_DT)	+= imx-cpufreq-dt.o
 obj-$(CONFIG_ARM_KIRKWOOD_CPUFREQ)	+= kirkwood-cpufreq.o
 obj-$(CONFIG_ARM_MEDIATEK_CPUFREQ)	+= mediatek-cpufreq.o
 obj-$(CONFIG_MACH_MVEBU_V7)		+= mvebu-cpufreq.o
 obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ)	+= omap-cpufreq.o
 obj-$(CONFIG_ARM_PXA2xx_CPUFREQ)	+= pxa2xx-cpufreq.o
diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
index 47729a22c159..19c1aad57e26 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -106,10 +106,13 @@ static const struct of_device_id whitelist[] __initconst = {
  */
 static const struct of_device_id blacklist[] __initconst = {
 	{ .compatible = "calxeda,highbank", },
 	{ .compatible = "calxeda,ecx-2000", },
 
+	{ .compatible = "fsl,imx8mq", },
+	{ .compatible = "fsl,imx8mm", },
+
 	{ .compatible = "marvell,armadaxp", },
 
 	{ .compatible = "mediatek,mt2701", },
 	{ .compatible = "mediatek,mt2712", },
 	{ .compatible = "mediatek,mt7622", },
diff --git a/drivers/cpufreq/imx-cpufreq-dt.c b/drivers/cpufreq/imx-cpufreq-dt.c
new file mode 100644
index 000000000000..9b2ee96c9213
--- /dev/null
+++ b/drivers/cpufreq/imx-cpufreq-dt.c
@@ -0,0 +1,99 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2019 NXP
+ */
+
+#include <linux/cpu.h>
+#include <linux/err.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/nvmem-consumer.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/pm_opp.h>
+#include <linux/slab.h>
+
+#define OCOTP_CFG3_SPEED_GRADE_SHIFT	8
+#define OCOTP_CFG3_SPEED_GRADE_MASK	(0x3 << 8)
+
+static const struct of_device_id imx_cpufreq_dt_match_list[] = {
+	{ .compatible = "fsl,imx8mm" },
+	{ .compatible = "fsl,imx8mq" },
+	{}
+};
+
+static const struct of_device_id *imx_cpufreq_dt_match_node(void)
+{
+	struct device_node *np;
+	const struct of_device_id *match;
+
+	np = of_find_node_by_path("/");
+	match = of_match_node(imx_cpufreq_dt_match_list, np);
+	of_node_put(np);
+
+	return match;
+}
+
+/* cpufreq-dt device registered by imx-cpufreq-dt */
+static struct platform_device *cpufreq_dt_pdev;
+static struct opp_table *cpufreq_opp_table;
+
+static int imx_cpufreq_dt_probe(struct platform_device *pdev)
+{
+	struct device *cpu_dev = get_cpu_device(0);
+	const struct of_device_id *match;
+	u32 speed_grade;
+	int ret;
+
+	match = imx_cpufreq_dt_match_node();
+	if (!match)
+		return -ENODEV;
+
+	ret = nvmem_cell_read_u32(cpu_dev, "speed_grade", &speed_grade);
+	if (ret)
+		return ret;
+
+	speed_grade = (speed_grade & OCOTP_CFG3_SPEED_GRADE_MASK) >> OCOTP_CFG3_SPEED_GRADE_SHIFT;
+	dev_info(&pdev->dev, "cpu speed grade %d\n", speed_grade);
+	speed_grade = 1 << speed_grade;
+
+	cpufreq_opp_table = dev_pm_opp_set_supported_hw(cpu_dev, &speed_grade, 1);
+	if (IS_ERR(cpufreq_opp_table)) {
+		ret = PTR_ERR(cpufreq_opp_table);
+		dev_err(&pdev->dev, "Failed to set supported opp: %d\n", ret);
+		return ret;
+	}
+
+	cpufreq_dt_pdev = platform_device_register_data(
+			&pdev->dev, "cpufreq-dt", -1, NULL, 0);
+	if (IS_ERR(cpufreq_dt_pdev)) {
+		dev_pm_opp_put_supported_hw(cpufreq_opp_table);
+		ret = PTR_ERR(cpufreq_dt_pdev);
+		dev_err(&pdev->dev, "Failed to register cpufreq-dt: %d\n", ret);
+		return ret;
+	}
+
+	return 0;
+}
+
+static int imx_cpufreq_dt_remove(struct platform_device *pdev)
+{
+	platform_device_unregister(cpufreq_dt_pdev);
+	dev_pm_opp_put_supported_hw(cpufreq_opp_table);
+
+	return 0;
+}
+
+static struct platform_driver imx_cpufreq_dt_driver = {
+	.probe = imx_cpufreq_dt_probe,
+	.remove = imx_cpufreq_dt_remove,
+	.driver = {
+		.name = "imx-cpufreq-dt",
+	},
+};
+module_platform_driver(imx_cpufreq_dt_driver);
+
+MODULE_ALIAS("platform:imx-cpufreq-dt");
+MODULE_DESCRIPTION("Freescale i.MX cpufreq speed grading driver");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/soc/imx/soc-imx8.c b/drivers/soc/imx/soc-imx8.c
index cd10726e64e4..02988bdfbb73 100644
--- a/drivers/soc/imx/soc-imx8.c
+++ b/drivers/soc/imx/soc-imx8.c
@@ -130,10 +130,13 @@ static int __init imx8_soc_init(void)
 
 	soc_dev = soc_device_register(soc_dev_attr);
 	if (IS_ERR(soc_dev))
 		goto free_rev;
 
+	if (IS_ENABLED(CONFIG_ARM_IMX_CPUFREQ_DT))
+		platform_device_register_simple("imx-cpufreq-dt", -1, NULL, 0);
+
 	return 0;
 
 free_rev:
 	kfree(soc_dev_attr->revision);
 free_soc:
-- 
2.17.1

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

^ permalink raw reply related	[flat|nested] 36+ messages in thread

* [PATCH v2 2/3] arm64: dts: imx8mm: Add cpu speed grading and all OPPs
@ 2019-05-02 22:44   ` Leonard Crestez
  0 siblings, 0 replies; 36+ messages in thread
From: Leonard Crestez @ 2019-05-02 22:44 UTC (permalink / raw)
  To: Viresh Kumar, Lucas Stach, Shawn Guo
  Cc: Aisheng Dong, Jacky Bai, Anson Huang, linux-pm,
	Rafael J. Wysocki, dl-linux-imx, kernel, Fabio Estevam,
	linux-arm-kernel, Abel Vesa

Add a nvmem cell on cpu node referencing speed grade and the 1.8 Ghz
cpufreq opp.

The imx-cpufreq-dt driver will read speed grade and disable higher opps
if unsupported.

Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
---
 arch/arm64/boot/dts/freescale/imx8mm.dtsi | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
index 0b2a585c5844..9154f48e81f4 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
@@ -51,10 +51,12 @@
 			clock-latency = <61036>; /* two CLK32 periods */
 			clocks = <&clk IMX8MM_CLK_ARM>;
 			enable-method = "psci";
 			next-level-cache = <&A53_L2>;
 			operating-points-v2 = <&a53_opp_table>;
+			nvmem-cells = <&cpu_speed_grade>;
+			nvmem-cell-names = "speed_grade";
 		};
 
 		A53_1: cpu@1 {
 			device_type = "cpu";
 			compatible = "arm,cortex-a53";
@@ -95,21 +97,36 @@
 
 	a53_opp_table: opp-table {
 		compatible = "operating-points-v2";
 		opp-shared;
 
+		opp-800000000 {
+			opp-hz = /bits/ 64 <800000000>;
+			opp-microvolt = <850000>;
+			opp-supported-hw = <0xf>;
+			clock-latency-ns = <150000>;
+		};
+
 		opp-1200000000 {
 			opp-hz = /bits/ 64 <1200000000>;
 			opp-microvolt = <850000>;
+			opp-supported-hw = <0xe>;
 			clock-latency-ns = <150000>;
 		};
 
 		opp-1600000000 {
 			opp-hz = /bits/ 64 <1600000000>;
 			opp-microvolt = <900000>;
+			opp-supported-hw = <0xc>;
+			clock-latency-ns = <150000>;
+		};
+
+		opp-1800000000 {
+			opp-hz = /bits/ 64 <1800000000>;
+			opp-microvolt = <1000000>;
+			opp-supported-hw = <0x8>;
 			clock-latency-ns = <150000>;
-			opp-suspend;
 		};
 	};
 
 	memory@40000000 {
 		device_type = "memory";
@@ -317,10 +334,14 @@
 				reg = <0x30350000 0x10000>;
 				clocks = <&clk IMX8MM_CLK_OCOTP_ROOT>;
 				/* For nvmem subnodes */
 				#address-cells = <1>;
 				#size-cells = <1>;
+
+				cpu_speed_grade: speed-grade@10 {
+					reg = <0x10 4>;
+				};
 			};
 
 			anatop: anatop@30360000 {
 				compatible = "fsl,imx8mm-anatop", "syscon", "simple-bus";
 				reg = <0x30360000 0x10000>;
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 36+ messages in thread

* [PATCH v2 2/3] arm64: dts: imx8mm: Add cpu speed grading and all OPPs
@ 2019-05-02 22:44   ` Leonard Crestez
  0 siblings, 0 replies; 36+ messages in thread
From: Leonard Crestez @ 2019-05-02 22:44 UTC (permalink / raw)
  To: Viresh Kumar, Lucas Stach, Shawn Guo
  Cc: Rafael J. Wysocki, Anson Huang, Jacky Bai, Abel Vesa,
	Aisheng Dong, Fabio Estevam, linux-pm, kernel, dl-linux-imx,
	linux-arm-kernel

Add a nvmem cell on cpu node referencing speed grade and the 1.8 Ghz
cpufreq opp.

The imx-cpufreq-dt driver will read speed grade and disable higher opps
if unsupported.

Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
---
 arch/arm64/boot/dts/freescale/imx8mm.dtsi | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
index 0b2a585c5844..9154f48e81f4 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
@@ -51,10 +51,12 @@
 			clock-latency = <61036>; /* two CLK32 periods */
 			clocks = <&clk IMX8MM_CLK_ARM>;
 			enable-method = "psci";
 			next-level-cache = <&A53_L2>;
 			operating-points-v2 = <&a53_opp_table>;
+			nvmem-cells = <&cpu_speed_grade>;
+			nvmem-cell-names = "speed_grade";
 		};
 
 		A53_1: cpu@1 {
 			device_type = "cpu";
 			compatible = "arm,cortex-a53";
@@ -95,21 +97,36 @@
 
 	a53_opp_table: opp-table {
 		compatible = "operating-points-v2";
 		opp-shared;
 
+		opp-800000000 {
+			opp-hz = /bits/ 64 <800000000>;
+			opp-microvolt = <850000>;
+			opp-supported-hw = <0xf>;
+			clock-latency-ns = <150000>;
+		};
+
 		opp-1200000000 {
 			opp-hz = /bits/ 64 <1200000000>;
 			opp-microvolt = <850000>;
+			opp-supported-hw = <0xe>;
 			clock-latency-ns = <150000>;
 		};
 
 		opp-1600000000 {
 			opp-hz = /bits/ 64 <1600000000>;
 			opp-microvolt = <900000>;
+			opp-supported-hw = <0xc>;
+			clock-latency-ns = <150000>;
+		};
+
+		opp-1800000000 {
+			opp-hz = /bits/ 64 <1800000000>;
+			opp-microvolt = <1000000>;
+			opp-supported-hw = <0x8>;
 			clock-latency-ns = <150000>;
-			opp-suspend;
 		};
 	};
 
 	memory@40000000 {
 		device_type = "memory";
@@ -317,10 +334,14 @@
 				reg = <0x30350000 0x10000>;
 				clocks = <&clk IMX8MM_CLK_OCOTP_ROOT>;
 				/* For nvmem subnodes */
 				#address-cells = <1>;
 				#size-cells = <1>;
+
+				cpu_speed_grade: speed-grade@10 {
+					reg = <0x10 4>;
+				};
 			};
 
 			anatop: anatop@30360000 {
 				compatible = "fsl,imx8mm-anatop", "syscon", "simple-bus";
 				reg = <0x30360000 0x10000>;
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 36+ messages in thread

* [PATCH v2 2/3] arm64: dts: imx8mm: Add cpu speed grading and all OPPs
@ 2019-05-02 22:44   ` Leonard Crestez
  0 siblings, 0 replies; 36+ messages in thread
From: Leonard Crestez @ 2019-05-02 22:44 UTC (permalink / raw)
  To: Viresh Kumar, Lucas Stach, Shawn Guo
  Cc: Aisheng Dong, Jacky Bai, Anson Huang, linux-pm,
	Rafael J. Wysocki, dl-linux-imx, kernel, Fabio Estevam,
	linux-arm-kernel, Abel Vesa

Add a nvmem cell on cpu node referencing speed grade and the 1.8 Ghz
cpufreq opp.

The imx-cpufreq-dt driver will read speed grade and disable higher opps
if unsupported.

Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
---
 arch/arm64/boot/dts/freescale/imx8mm.dtsi | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
index 0b2a585c5844..9154f48e81f4 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
@@ -51,10 +51,12 @@
 			clock-latency = <61036>; /* two CLK32 periods */
 			clocks = <&clk IMX8MM_CLK_ARM>;
 			enable-method = "psci";
 			next-level-cache = <&A53_L2>;
 			operating-points-v2 = <&a53_opp_table>;
+			nvmem-cells = <&cpu_speed_grade>;
+			nvmem-cell-names = "speed_grade";
 		};
 
 		A53_1: cpu@1 {
 			device_type = "cpu";
 			compatible = "arm,cortex-a53";
@@ -95,21 +97,36 @@
 
 	a53_opp_table: opp-table {
 		compatible = "operating-points-v2";
 		opp-shared;
 
+		opp-800000000 {
+			opp-hz = /bits/ 64 <800000000>;
+			opp-microvolt = <850000>;
+			opp-supported-hw = <0xf>;
+			clock-latency-ns = <150000>;
+		};
+
 		opp-1200000000 {
 			opp-hz = /bits/ 64 <1200000000>;
 			opp-microvolt = <850000>;
+			opp-supported-hw = <0xe>;
 			clock-latency-ns = <150000>;
 		};
 
 		opp-1600000000 {
 			opp-hz = /bits/ 64 <1600000000>;
 			opp-microvolt = <900000>;
+			opp-supported-hw = <0xc>;
+			clock-latency-ns = <150000>;
+		};
+
+		opp-1800000000 {
+			opp-hz = /bits/ 64 <1800000000>;
+			opp-microvolt = <1000000>;
+			opp-supported-hw = <0x8>;
 			clock-latency-ns = <150000>;
-			opp-suspend;
 		};
 	};
 
 	memory@40000000 {
 		device_type = "memory";
@@ -317,10 +334,14 @@
 				reg = <0x30350000 0x10000>;
 				clocks = <&clk IMX8MM_CLK_OCOTP_ROOT>;
 				/* For nvmem subnodes */
 				#address-cells = <1>;
 				#size-cells = <1>;
+
+				cpu_speed_grade: speed-grade@10 {
+					reg = <0x10 4>;
+				};
 			};
 
 			anatop: anatop@30360000 {
 				compatible = "fsl,imx8mm-anatop", "syscon", "simple-bus";
 				reg = <0x30360000 0x10000>;
-- 
2.17.1

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

^ permalink raw reply related	[flat|nested] 36+ messages in thread

* [PATCH v2 3/3] arm64: dts: imx8mq: Add cpu speed grading and all OPPs
@ 2019-05-02 22:44   ` Leonard Crestez
  0 siblings, 0 replies; 36+ messages in thread
From: Leonard Crestez @ 2019-05-02 22:44 UTC (permalink / raw)
  To: Viresh Kumar, Lucas Stach, Shawn Guo
  Cc: Aisheng Dong, Jacky Bai, Anson Huang, linux-pm,
	Rafael J. Wysocki, dl-linux-imx, kernel, Fabio Estevam,
	linux-arm-kernel, Abel Vesa

Add nvmem-cells reference to cpu and fill the OPP table with all known
OPPs.

Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
---
 arch/arm64/boot/dts/freescale/imx8mq.dtsi | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
index 6d635ba0904c..f03f9be24f44 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
@@ -93,10 +93,12 @@
 			clocks = <&clk IMX8MQ_CLK_ARM>;
 			enable-method = "psci";
 			next-level-cache = <&A53_L2>;
 			operating-points-v2 = <&a53_opp_table>;
 			#cooling-cells = <2>;
+			nvmem-cells = <&cpu_speed_grade>;
+			nvmem-cell-names = "speed_grade";
 		};
 
 		A53_1: cpu@1 {
 			device_type = "cpu";
 			compatible = "arm,cortex-a53";
@@ -143,18 +145,33 @@
 		opp-shared;
 
 		opp-800000000 {
 			opp-hz = /bits/ 64 <800000000>;
 			opp-microvolt = <900000>;
+			opp-supported-hw = <0xf>;
+			clock-latency-ns = <150000>;
+		};
+
+		opp-1000000000 {
+			opp-hz = /bits/ 64 <1000000000>;
+			opp-microvolt = <900000>;
+			opp-supported-hw = <0xe>;
 			clock-latency-ns = <150000>;
 		};
 
 		opp-1300000000 {
 			opp-hz = /bits/ 64 <1300000000>;
 			opp-microvolt = <1000000>;
+			opp-supported-hw = <0xc>;
+			clock-latency-ns = <150000>;
+		};
+
+		opp-1500000000 {
+			opp-hz = /bits/ 64 <1500000000>;
+			opp-microvolt = <1000000>;
+			opp-supported-hw = <0x8>;
 			clock-latency-ns = <150000>;
-			opp-suspend;
 		};
 	};
 
 	pmu {
 		compatible = "arm,cortex-a53-pmu";
@@ -413,10 +430,14 @@
 				compatible = "fsl,imx8mq-ocotp", "syscon";
 				reg = <0x30350000 0x10000>;
 				clocks = <&clk IMX8MQ_CLK_OCOTP_ROOT>;
 				#address-cells = <1>;
 				#size-cells = <1>;
+
+				cpu_speed_grade: speed-grade@10 {
+					reg = <0x10 4>;
+				};
 			};
 
 			anatop: syscon@30360000 {
 				compatible = "fsl,imx8mq-anatop", "syscon";
 				reg = <0x30360000 0x10000>;
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 36+ messages in thread

* [PATCH v2 3/3] arm64: dts: imx8mq: Add cpu speed grading and all OPPs
@ 2019-05-02 22:44   ` Leonard Crestez
  0 siblings, 0 replies; 36+ messages in thread
From: Leonard Crestez @ 2019-05-02 22:44 UTC (permalink / raw)
  To: Viresh Kumar, Lucas Stach, Shawn Guo
  Cc: Rafael J. Wysocki, Anson Huang, Jacky Bai, Abel Vesa,
	Aisheng Dong, Fabio Estevam, linux-pm, kernel, dl-linux-imx,
	linux-arm-kernel

Add nvmem-cells reference to cpu and fill the OPP table with all known
OPPs.

Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
---
 arch/arm64/boot/dts/freescale/imx8mq.dtsi | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
index 6d635ba0904c..f03f9be24f44 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
@@ -93,10 +93,12 @@
 			clocks = <&clk IMX8MQ_CLK_ARM>;
 			enable-method = "psci";
 			next-level-cache = <&A53_L2>;
 			operating-points-v2 = <&a53_opp_table>;
 			#cooling-cells = <2>;
+			nvmem-cells = <&cpu_speed_grade>;
+			nvmem-cell-names = "speed_grade";
 		};
 
 		A53_1: cpu@1 {
 			device_type = "cpu";
 			compatible = "arm,cortex-a53";
@@ -143,18 +145,33 @@
 		opp-shared;
 
 		opp-800000000 {
 			opp-hz = /bits/ 64 <800000000>;
 			opp-microvolt = <900000>;
+			opp-supported-hw = <0xf>;
+			clock-latency-ns = <150000>;
+		};
+
+		opp-1000000000 {
+			opp-hz = /bits/ 64 <1000000000>;
+			opp-microvolt = <900000>;
+			opp-supported-hw = <0xe>;
 			clock-latency-ns = <150000>;
 		};
 
 		opp-1300000000 {
 			opp-hz = /bits/ 64 <1300000000>;
 			opp-microvolt = <1000000>;
+			opp-supported-hw = <0xc>;
+			clock-latency-ns = <150000>;
+		};
+
+		opp-1500000000 {
+			opp-hz = /bits/ 64 <1500000000>;
+			opp-microvolt = <1000000>;
+			opp-supported-hw = <0x8>;
 			clock-latency-ns = <150000>;
-			opp-suspend;
 		};
 	};
 
 	pmu {
 		compatible = "arm,cortex-a53-pmu";
@@ -413,10 +430,14 @@
 				compatible = "fsl,imx8mq-ocotp", "syscon";
 				reg = <0x30350000 0x10000>;
 				clocks = <&clk IMX8MQ_CLK_OCOTP_ROOT>;
 				#address-cells = <1>;
 				#size-cells = <1>;
+
+				cpu_speed_grade: speed-grade@10 {
+					reg = <0x10 4>;
+				};
 			};
 
 			anatop: syscon@30360000 {
 				compatible = "fsl,imx8mq-anatop", "syscon";
 				reg = <0x30360000 0x10000>;
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 36+ messages in thread

* [PATCH v2 3/3] arm64: dts: imx8mq: Add cpu speed grading and all OPPs
@ 2019-05-02 22:44   ` Leonard Crestez
  0 siblings, 0 replies; 36+ messages in thread
From: Leonard Crestez @ 2019-05-02 22:44 UTC (permalink / raw)
  To: Viresh Kumar, Lucas Stach, Shawn Guo
  Cc: Aisheng Dong, Jacky Bai, Anson Huang, linux-pm,
	Rafael J. Wysocki, dl-linux-imx, kernel, Fabio Estevam,
	linux-arm-kernel, Abel Vesa

Add nvmem-cells reference to cpu and fill the OPP table with all known
OPPs.

Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
---
 arch/arm64/boot/dts/freescale/imx8mq.dtsi | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
index 6d635ba0904c..f03f9be24f44 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
@@ -93,10 +93,12 @@
 			clocks = <&clk IMX8MQ_CLK_ARM>;
 			enable-method = "psci";
 			next-level-cache = <&A53_L2>;
 			operating-points-v2 = <&a53_opp_table>;
 			#cooling-cells = <2>;
+			nvmem-cells = <&cpu_speed_grade>;
+			nvmem-cell-names = "speed_grade";
 		};
 
 		A53_1: cpu@1 {
 			device_type = "cpu";
 			compatible = "arm,cortex-a53";
@@ -143,18 +145,33 @@
 		opp-shared;
 
 		opp-800000000 {
 			opp-hz = /bits/ 64 <800000000>;
 			opp-microvolt = <900000>;
+			opp-supported-hw = <0xf>;
+			clock-latency-ns = <150000>;
+		};
+
+		opp-1000000000 {
+			opp-hz = /bits/ 64 <1000000000>;
+			opp-microvolt = <900000>;
+			opp-supported-hw = <0xe>;
 			clock-latency-ns = <150000>;
 		};
 
 		opp-1300000000 {
 			opp-hz = /bits/ 64 <1300000000>;
 			opp-microvolt = <1000000>;
+			opp-supported-hw = <0xc>;
+			clock-latency-ns = <150000>;
+		};
+
+		opp-1500000000 {
+			opp-hz = /bits/ 64 <1500000000>;
+			opp-microvolt = <1000000>;
+			opp-supported-hw = <0x8>;
 			clock-latency-ns = <150000>;
-			opp-suspend;
 		};
 	};
 
 	pmu {
 		compatible = "arm,cortex-a53-pmu";
@@ -413,10 +430,14 @@
 				compatible = "fsl,imx8mq-ocotp", "syscon";
 				reg = <0x30350000 0x10000>;
 				clocks = <&clk IMX8MQ_CLK_OCOTP_ROOT>;
 				#address-cells = <1>;
 				#size-cells = <1>;
+
+				cpu_speed_grade: speed-grade@10 {
+					reg = <0x10 4>;
+				};
 			};
 
 			anatop: syscon@30360000 {
 				compatible = "fsl,imx8mq-anatop", "syscon";
 				reg = <0x30360000 0x10000>;
-- 
2.17.1

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

^ permalink raw reply related	[flat|nested] 36+ messages in thread

* Re: [PATCH v2 0/3] cpufreq: Add imx-cpufreq-dt driver
@ 2019-05-03  6:50   ` Viresh Kumar
  0 siblings, 0 replies; 36+ messages in thread
From: Viresh Kumar @ 2019-05-03  6:50 UTC (permalink / raw)
  To: Leonard Crestez
  Cc: Aisheng Dong, Abel Vesa, Anson Huang, linux-pm,
	Rafael J. Wysocki, dl-linux-imx, kernel, Fabio Estevam,
	Lucas Stach, Shawn Guo, linux-arm-kernel, Jacky Bai

On 02-05-19, 22:44, Leonard Crestez wrote:
> Right now in upstream imx8m cpufreq support just lists a common subset
> of OPPs because the higher ones should only be attempted after checking
> speed grading in fuses.
> 
> Add a small driver which checks speed grading from nvmem cells before
> registering cpufreq-dt.
> 
> ---
> 
> By default kconfig builds it as a module even though it's very small.
> Couldn't find a way for MODULE_DEVICE_TABLE to match on root node compat
> string and there was no other appropriate node so register the
> imx-cpufreq-dt platfrom device directly from imx8 soc driver instead. I
> checked module is probed by default and rmmod/modprobe again works.

I have suggested something in 1/3 for this.

> It seems that cpufreq-dt insists on adding the opp and regulator itself
> so can't actually call dev_pm_opp_of_add_table and then
> dev_pm_opp_disable

Well we can surely implement it someway if that is what you want, like we can
pass postinit() callback in platform data to cpufreq-dt which can get called
after OPP table is added, etc.

But disabling OPPs after they are added isn't a great way of handling it as
well.

> so implementation was switched to opp-supported-hw.

I will say that this is far better than disabling the OPPs after adding them. So
this is a good way of doing it.

> Maybe I'm confused by API quirks?
> 
> The market segment logic was dropped because I couldn't find any good
> references in datasheets for why lower or intermediary OPPs should be
> disabled on certain market segments. Using opp-supported-hw means that
> adding this in the future would require changing flags inside DT instead
> of code, that seems undesirable for DT compat reasons.
> 
> This could also be extended to mach-imx7d speed grading.
> 
> I never noticed anything wrong with going above the fused speed grading
> however it's technically unsafe so the cpufreq parts should go in before
> DT changes.
> 
> Other changes since v1:
>  * Turn into a proper module
>  * Support imx8mq
> Link to v1 (RFC): https://patchwork.kernel.org/patch/10916769/
> 
> Leonard Crestez (3):
>   cpufreq: Add imx-cpufreq-dt driver
>   arm64: dts: imx8mm: Add cpu speed grading and all OPPs
>   arm64: dts: imx8mq: Add cpu speed grading and all OPPs
> 
>  arch/arm64/boot/dts/freescale/imx8mm.dtsi | 23 +++++-
>  arch/arm64/boot/dts/freescale/imx8mq.dtsi | 23 +++++-
>  drivers/cpufreq/Kconfig.arm               | 10 +++
>  drivers/cpufreq/Makefile                  |  1 +
>  drivers/cpufreq/cpufreq-dt-platdev.c      |  3 +
>  drivers/cpufreq/imx-cpufreq-dt.c          | 99 +++++++++++++++++++++++
>  drivers/soc/imx/soc-imx8.c                |  3 +
>  7 files changed, 160 insertions(+), 2 deletions(-)
>  create mode 100644 drivers/cpufreq/imx-cpufreq-dt.c
> 
> -- 
> 2.17.1
> 

-- 
viresh

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH v2 0/3] cpufreq: Add imx-cpufreq-dt driver
@ 2019-05-03  6:50   ` Viresh Kumar
  0 siblings, 0 replies; 36+ messages in thread
From: Viresh Kumar @ 2019-05-03  6:50 UTC (permalink / raw)
  To: Leonard Crestez
  Cc: Lucas Stach, Shawn Guo, Rafael J. Wysocki, Anson Huang,
	Jacky Bai, Abel Vesa, Aisheng Dong, Fabio Estevam, linux-pm,
	kernel, dl-linux-imx, linux-arm-kernel

On 02-05-19, 22:44, Leonard Crestez wrote:
> Right now in upstream imx8m cpufreq support just lists a common subset
> of OPPs because the higher ones should only be attempted after checking
> speed grading in fuses.
> 
> Add a small driver which checks speed grading from nvmem cells before
> registering cpufreq-dt.
> 
> ---
> 
> By default kconfig builds it as a module even though it's very small.
> Couldn't find a way for MODULE_DEVICE_TABLE to match on root node compat
> string and there was no other appropriate node so register the
> imx-cpufreq-dt platfrom device directly from imx8 soc driver instead. I
> checked module is probed by default and rmmod/modprobe again works.

I have suggested something in 1/3 for this.

> It seems that cpufreq-dt insists on adding the opp and regulator itself
> so can't actually call dev_pm_opp_of_add_table and then
> dev_pm_opp_disable

Well we can surely implement it someway if that is what you want, like we can
pass postinit() callback in platform data to cpufreq-dt which can get called
after OPP table is added, etc.

But disabling OPPs after they are added isn't a great way of handling it as
well.

> so implementation was switched to opp-supported-hw.

I will say that this is far better than disabling the OPPs after adding them. So
this is a good way of doing it.

> Maybe I'm confused by API quirks?
> 
> The market segment logic was dropped because I couldn't find any good
> references in datasheets for why lower or intermediary OPPs should be
> disabled on certain market segments. Using opp-supported-hw means that
> adding this in the future would require changing flags inside DT instead
> of code, that seems undesirable for DT compat reasons.
> 
> This could also be extended to mach-imx7d speed grading.
> 
> I never noticed anything wrong with going above the fused speed grading
> however it's technically unsafe so the cpufreq parts should go in before
> DT changes.
> 
> Other changes since v1:
>  * Turn into a proper module
>  * Support imx8mq
> Link to v1 (RFC): https://patchwork.kernel.org/patch/10916769/
> 
> Leonard Crestez (3):
>   cpufreq: Add imx-cpufreq-dt driver
>   arm64: dts: imx8mm: Add cpu speed grading and all OPPs
>   arm64: dts: imx8mq: Add cpu speed grading and all OPPs
> 
>  arch/arm64/boot/dts/freescale/imx8mm.dtsi | 23 +++++-
>  arch/arm64/boot/dts/freescale/imx8mq.dtsi | 23 +++++-
>  drivers/cpufreq/Kconfig.arm               | 10 +++
>  drivers/cpufreq/Makefile                  |  1 +
>  drivers/cpufreq/cpufreq-dt-platdev.c      |  3 +
>  drivers/cpufreq/imx-cpufreq-dt.c          | 99 +++++++++++++++++++++++
>  drivers/soc/imx/soc-imx8.c                |  3 +
>  7 files changed, 160 insertions(+), 2 deletions(-)
>  create mode 100644 drivers/cpufreq/imx-cpufreq-dt.c
> 
> -- 
> 2.17.1
> 

-- 
viresh

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH v2 0/3] cpufreq: Add imx-cpufreq-dt driver
@ 2019-05-03  6:50   ` Viresh Kumar
  0 siblings, 0 replies; 36+ messages in thread
From: Viresh Kumar @ 2019-05-03  6:50 UTC (permalink / raw)
  To: Leonard Crestez
  Cc: Aisheng Dong, Abel Vesa, Anson Huang, linux-pm,
	Rafael J. Wysocki, dl-linux-imx, kernel, Fabio Estevam,
	Lucas Stach, Shawn Guo, linux-arm-kernel, Jacky Bai

On 02-05-19, 22:44, Leonard Crestez wrote:
> Right now in upstream imx8m cpufreq support just lists a common subset
> of OPPs because the higher ones should only be attempted after checking
> speed grading in fuses.
> 
> Add a small driver which checks speed grading from nvmem cells before
> registering cpufreq-dt.
> 
> ---
> 
> By default kconfig builds it as a module even though it's very small.
> Couldn't find a way for MODULE_DEVICE_TABLE to match on root node compat
> string and there was no other appropriate node so register the
> imx-cpufreq-dt platfrom device directly from imx8 soc driver instead. I
> checked module is probed by default and rmmod/modprobe again works.

I have suggested something in 1/3 for this.

> It seems that cpufreq-dt insists on adding the opp and regulator itself
> so can't actually call dev_pm_opp_of_add_table and then
> dev_pm_opp_disable

Well we can surely implement it someway if that is what you want, like we can
pass postinit() callback in platform data to cpufreq-dt which can get called
after OPP table is added, etc.

But disabling OPPs after they are added isn't a great way of handling it as
well.

> so implementation was switched to opp-supported-hw.

I will say that this is far better than disabling the OPPs after adding them. So
this is a good way of doing it.

> Maybe I'm confused by API quirks?
> 
> The market segment logic was dropped because I couldn't find any good
> references in datasheets for why lower or intermediary OPPs should be
> disabled on certain market segments. Using opp-supported-hw means that
> adding this in the future would require changing flags inside DT instead
> of code, that seems undesirable for DT compat reasons.
> 
> This could also be extended to mach-imx7d speed grading.
> 
> I never noticed anything wrong with going above the fused speed grading
> however it's technically unsafe so the cpufreq parts should go in before
> DT changes.
> 
> Other changes since v1:
>  * Turn into a proper module
>  * Support imx8mq
> Link to v1 (RFC): https://patchwork.kernel.org/patch/10916769/
> 
> Leonard Crestez (3):
>   cpufreq: Add imx-cpufreq-dt driver
>   arm64: dts: imx8mm: Add cpu speed grading and all OPPs
>   arm64: dts: imx8mq: Add cpu speed grading and all OPPs
> 
>  arch/arm64/boot/dts/freescale/imx8mm.dtsi | 23 +++++-
>  arch/arm64/boot/dts/freescale/imx8mq.dtsi | 23 +++++-
>  drivers/cpufreq/Kconfig.arm               | 10 +++
>  drivers/cpufreq/Makefile                  |  1 +
>  drivers/cpufreq/cpufreq-dt-platdev.c      |  3 +
>  drivers/cpufreq/imx-cpufreq-dt.c          | 99 +++++++++++++++++++++++
>  drivers/soc/imx/soc-imx8.c                |  3 +
>  7 files changed, 160 insertions(+), 2 deletions(-)
>  create mode 100644 drivers/cpufreq/imx-cpufreq-dt.c
> 
> -- 
> 2.17.1
> 

-- 
viresh

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

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH v2 1/3] cpufreq: Add imx-cpufreq-dt driver
@ 2019-05-03  6:52     ` Viresh Kumar
  0 siblings, 0 replies; 36+ messages in thread
From: Viresh Kumar @ 2019-05-03  6:52 UTC (permalink / raw)
  To: Leonard Crestez
  Cc: Aisheng Dong, Abel Vesa, Anson Huang, linux-pm,
	Rafael J. Wysocki, dl-linux-imx, kernel, Fabio Estevam,
	Lucas Stach, Shawn Guo, linux-arm-kernel, Jacky Bai

On 02-05-19, 22:44, Leonard Crestez wrote:
> Right now in upstream imx8m cpufreq support just lists a common subset
> of OPPs because the higher ones should only be attempted after checking
> speed grading in fuses.
> 
> Add a small driver which checks speed grading from nvmem cells before
> registering cpufreq-dt.
> 
> This allows unlocking all frequencies for imx8mm and imx8mq.
> 
> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
> 
> ---
>  drivers/cpufreq/Kconfig.arm          | 10 +++
>  drivers/cpufreq/Makefile             |  1 +
>  drivers/cpufreq/cpufreq-dt-platdev.c |  3 +
>  drivers/cpufreq/imx-cpufreq-dt.c     | 99 ++++++++++++++++++++++++++++
>  drivers/soc/imx/soc-imx8.c           |  3 +
>  5 files changed, 116 insertions(+)
>  create mode 100644 drivers/cpufreq/imx-cpufreq-dt.c
> 
> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> index 179a1d302f48..f8e40429e290 100644
> --- a/drivers/cpufreq/Kconfig.arm
> +++ b/drivers/cpufreq/Kconfig.arm
> @@ -90,10 +90,20 @@ config ARM_IMX6Q_CPUFREQ
>  	help
>  	  This adds cpufreq driver support for Freescale i.MX6 series SoCs.
>  
>  	  If in doubt, say N.
>  
> +config ARM_IMX_CPUFREQ_DT
> +	tristate "Freescale i.MX8M cpufreq support"
> +	depends on ARCH_MXC && CPUFREQ_DT
> +	default m if (ARCH_MXC && CPUFREQ_DT)

The if () part looks redundant here, why do you need it ?

> +	help
> +	  This adds cpufreq driver support for newer Freescale i.MX series

"newer" is a relative thing, it won't be newer an year or two later. Just drop
it.

> +	  SoCs, based on cpufreq-dt

Full stop (.) missing.

> +
> +	  If in doubt, say N.
> +
>  config ARM_KIRKWOOD_CPUFREQ
>  	def_bool MACH_KIRKWOOD
>  	help
>  	  This adds the CPUFreq driver for Marvell Kirkwood
>  	  SoCs.
> diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
> index 689b26c6f949..7bcda2273d0c 100644
> --- a/drivers/cpufreq/Makefile
> +++ b/drivers/cpufreq/Makefile
> @@ -54,10 +54,11 @@ obj-$(CONFIG_ARM_ARMADA_8K_CPUFREQ)	+= armada-8k-cpufreq.o
>  obj-$(CONFIG_ARM_BRCMSTB_AVS_CPUFREQ)	+= brcmstb-avs-cpufreq.o
>  obj-$(CONFIG_ACPI_CPPC_CPUFREQ)		+= cppc_cpufreq.o
>  obj-$(CONFIG_ARCH_DAVINCI)		+= davinci-cpufreq.o
>  obj-$(CONFIG_ARM_HIGHBANK_CPUFREQ)	+= highbank-cpufreq.o
>  obj-$(CONFIG_ARM_IMX6Q_CPUFREQ)		+= imx6q-cpufreq.o
> +obj-$(CONFIG_ARM_IMX_CPUFREQ_DT)	+= imx-cpufreq-dt.o
>  obj-$(CONFIG_ARM_KIRKWOOD_CPUFREQ)	+= kirkwood-cpufreq.o
>  obj-$(CONFIG_ARM_MEDIATEK_CPUFREQ)	+= mediatek-cpufreq.o
>  obj-$(CONFIG_MACH_MVEBU_V7)		+= mvebu-cpufreq.o
>  obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ)	+= omap-cpufreq.o
>  obj-$(CONFIG_ARM_PXA2xx_CPUFREQ)	+= pxa2xx-cpufreq.o
> diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
> index 47729a22c159..19c1aad57e26 100644
> --- a/drivers/cpufreq/cpufreq-dt-platdev.c
> +++ b/drivers/cpufreq/cpufreq-dt-platdev.c
> @@ -106,10 +106,13 @@ static const struct of_device_id whitelist[] __initconst = {
>   */
>  static const struct of_device_id blacklist[] __initconst = {
>  	{ .compatible = "calxeda,highbank", },
>  	{ .compatible = "calxeda,ecx-2000", },
>  
> +	{ .compatible = "fsl,imx8mq", },
> +	{ .compatible = "fsl,imx8mm", },
> +
>  	{ .compatible = "marvell,armadaxp", },
>  
>  	{ .compatible = "mediatek,mt2701", },
>  	{ .compatible = "mediatek,mt2712", },
>  	{ .compatible = "mediatek,mt7622", },
> diff --git a/drivers/cpufreq/imx-cpufreq-dt.c b/drivers/cpufreq/imx-cpufreq-dt.c
> new file mode 100644
> index 000000000000..9b2ee96c9213
> --- /dev/null
> +++ b/drivers/cpufreq/imx-cpufreq-dt.c
> @@ -0,0 +1,99 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright 2019 NXP
> + */
> +
> +#include <linux/cpu.h>
> +#include <linux/err.h>
> +#include <linux/init.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/nvmem-consumer.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/pm_opp.h>
> +#include <linux/slab.h>
> +
> +#define OCOTP_CFG3_SPEED_GRADE_SHIFT	8
> +#define OCOTP_CFG3_SPEED_GRADE_MASK	(0x3 << 8)
> +
> +static const struct of_device_id imx_cpufreq_dt_match_list[] = {
> +	{ .compatible = "fsl,imx8mm" },
> +	{ .compatible = "fsl,imx8mq" },
> +	{}
> +};
> +
> +static const struct of_device_id *imx_cpufreq_dt_match_node(void)
> +{
> +	struct device_node *np;
> +	const struct of_device_id *match;
> +
> +	np = of_find_node_by_path("/");
> +	match = of_match_node(imx_cpufreq_dt_match_list, np);
> +	of_node_put(np);
> +
> +	return match;
> +}
> +
> +/* cpufreq-dt device registered by imx-cpufreq-dt */
> +static struct platform_device *cpufreq_dt_pdev;
> +static struct opp_table *cpufreq_opp_table;
> +
> +static int imx_cpufreq_dt_probe(struct platform_device *pdev)
> +{
> +	struct device *cpu_dev = get_cpu_device(0);
> +	const struct of_device_id *match;
> +	u32 speed_grade;
> +	int ret;
> +
> +	match = imx_cpufreq_dt_match_node();

Just open code it here.

> +	if (!match)
> +		return -ENODEV;
> +
> +	ret = nvmem_cell_read_u32(cpu_dev, "speed_grade", &speed_grade);
> +	if (ret)
> +		return ret;
> +
> +	speed_grade = (speed_grade & OCOTP_CFG3_SPEED_GRADE_MASK) >> OCOTP_CFG3_SPEED_GRADE_SHIFT;
> +	dev_info(&pdev->dev, "cpu speed grade %d\n", speed_grade);
> +	speed_grade = 1 << speed_grade;
> +
> +	cpufreq_opp_table = dev_pm_opp_set_supported_hw(cpu_dev, &speed_grade, 1);
> +	if (IS_ERR(cpufreq_opp_table)) {
> +		ret = PTR_ERR(cpufreq_opp_table);
> +		dev_err(&pdev->dev, "Failed to set supported opp: %d\n", ret);
> +		return ret;
> +	}
> +
> +	cpufreq_dt_pdev = platform_device_register_data(
> +			&pdev->dev, "cpufreq-dt", -1, NULL, 0);
> +	if (IS_ERR(cpufreq_dt_pdev)) {
> +		dev_pm_opp_put_supported_hw(cpufreq_opp_table);
> +		ret = PTR_ERR(cpufreq_dt_pdev);
> +		dev_err(&pdev->dev, "Failed to register cpufreq-dt: %d\n", ret);
> +		return ret;
> +	}
> +
> +	return 0;
> +}
> +
> +static int imx_cpufreq_dt_remove(struct platform_device *pdev)
> +{
> +	platform_device_unregister(cpufreq_dt_pdev);
> +	dev_pm_opp_put_supported_hw(cpufreq_opp_table);
> +
> +	return 0;
> +}
> +
> +static struct platform_driver imx_cpufreq_dt_driver = {
> +	.probe = imx_cpufreq_dt_probe,
> +	.remove = imx_cpufreq_dt_remove,
> +	.driver = {
> +		.name = "imx-cpufreq-dt",
> +	},
> +};
> +module_platform_driver(imx_cpufreq_dt_driver);

Why add another virtual device-driver pair here? The only reason why we have
been adding it was to get deferred probe to work which doesn't look like the
case for this driver. Why not do everything from the init() routine ?

> +
> +MODULE_ALIAS("platform:imx-cpufreq-dt");
> +MODULE_DESCRIPTION("Freescale i.MX cpufreq speed grading driver");
> +MODULE_LICENSE("GPL v2");
> diff --git a/drivers/soc/imx/soc-imx8.c b/drivers/soc/imx/soc-imx8.c
> index cd10726e64e4..02988bdfbb73 100644
> --- a/drivers/soc/imx/soc-imx8.c
> +++ b/drivers/soc/imx/soc-imx8.c
> @@ -130,10 +130,13 @@ static int __init imx8_soc_init(void)
>  
>  	soc_dev = soc_device_register(soc_dev_attr);
>  	if (IS_ERR(soc_dev))
>  		goto free_rev;
>  
> +	if (IS_ENABLED(CONFIG_ARM_IMX_CPUFREQ_DT))
> +		platform_device_register_simple("imx-cpufreq-dt", -1, NULL, 0);
> +
>  	return 0;
>  
>  free_rev:
>  	kfree(soc_dev_attr->revision);
>  free_soc:
> -- 
> 2.17.1
> 

-- 
viresh

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH v2 1/3] cpufreq: Add imx-cpufreq-dt driver
@ 2019-05-03  6:52     ` Viresh Kumar
  0 siblings, 0 replies; 36+ messages in thread
From: Viresh Kumar @ 2019-05-03  6:52 UTC (permalink / raw)
  To: Leonard Crestez
  Cc: Lucas Stach, Shawn Guo, Rafael J. Wysocki, Anson Huang,
	Jacky Bai, Abel Vesa, Aisheng Dong, Fabio Estevam, linux-pm,
	kernel, dl-linux-imx, linux-arm-kernel

On 02-05-19, 22:44, Leonard Crestez wrote:
> Right now in upstream imx8m cpufreq support just lists a common subset
> of OPPs because the higher ones should only be attempted after checking
> speed grading in fuses.
> 
> Add a small driver which checks speed grading from nvmem cells before
> registering cpufreq-dt.
> 
> This allows unlocking all frequencies for imx8mm and imx8mq.
> 
> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
> 
> ---
>  drivers/cpufreq/Kconfig.arm          | 10 +++
>  drivers/cpufreq/Makefile             |  1 +
>  drivers/cpufreq/cpufreq-dt-platdev.c |  3 +
>  drivers/cpufreq/imx-cpufreq-dt.c     | 99 ++++++++++++++++++++++++++++
>  drivers/soc/imx/soc-imx8.c           |  3 +
>  5 files changed, 116 insertions(+)
>  create mode 100644 drivers/cpufreq/imx-cpufreq-dt.c
> 
> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> index 179a1d302f48..f8e40429e290 100644
> --- a/drivers/cpufreq/Kconfig.arm
> +++ b/drivers/cpufreq/Kconfig.arm
> @@ -90,10 +90,20 @@ config ARM_IMX6Q_CPUFREQ
>  	help
>  	  This adds cpufreq driver support for Freescale i.MX6 series SoCs.
>  
>  	  If in doubt, say N.
>  
> +config ARM_IMX_CPUFREQ_DT
> +	tristate "Freescale i.MX8M cpufreq support"
> +	depends on ARCH_MXC && CPUFREQ_DT
> +	default m if (ARCH_MXC && CPUFREQ_DT)

The if () part looks redundant here, why do you need it ?

> +	help
> +	  This adds cpufreq driver support for newer Freescale i.MX series

"newer" is a relative thing, it won't be newer an year or two later. Just drop
it.

> +	  SoCs, based on cpufreq-dt

Full stop (.) missing.

> +
> +	  If in doubt, say N.
> +
>  config ARM_KIRKWOOD_CPUFREQ
>  	def_bool MACH_KIRKWOOD
>  	help
>  	  This adds the CPUFreq driver for Marvell Kirkwood
>  	  SoCs.
> diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
> index 689b26c6f949..7bcda2273d0c 100644
> --- a/drivers/cpufreq/Makefile
> +++ b/drivers/cpufreq/Makefile
> @@ -54,10 +54,11 @@ obj-$(CONFIG_ARM_ARMADA_8K_CPUFREQ)	+= armada-8k-cpufreq.o
>  obj-$(CONFIG_ARM_BRCMSTB_AVS_CPUFREQ)	+= brcmstb-avs-cpufreq.o
>  obj-$(CONFIG_ACPI_CPPC_CPUFREQ)		+= cppc_cpufreq.o
>  obj-$(CONFIG_ARCH_DAVINCI)		+= davinci-cpufreq.o
>  obj-$(CONFIG_ARM_HIGHBANK_CPUFREQ)	+= highbank-cpufreq.o
>  obj-$(CONFIG_ARM_IMX6Q_CPUFREQ)		+= imx6q-cpufreq.o
> +obj-$(CONFIG_ARM_IMX_CPUFREQ_DT)	+= imx-cpufreq-dt.o
>  obj-$(CONFIG_ARM_KIRKWOOD_CPUFREQ)	+= kirkwood-cpufreq.o
>  obj-$(CONFIG_ARM_MEDIATEK_CPUFREQ)	+= mediatek-cpufreq.o
>  obj-$(CONFIG_MACH_MVEBU_V7)		+= mvebu-cpufreq.o
>  obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ)	+= omap-cpufreq.o
>  obj-$(CONFIG_ARM_PXA2xx_CPUFREQ)	+= pxa2xx-cpufreq.o
> diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
> index 47729a22c159..19c1aad57e26 100644
> --- a/drivers/cpufreq/cpufreq-dt-platdev.c
> +++ b/drivers/cpufreq/cpufreq-dt-platdev.c
> @@ -106,10 +106,13 @@ static const struct of_device_id whitelist[] __initconst = {
>   */
>  static const struct of_device_id blacklist[] __initconst = {
>  	{ .compatible = "calxeda,highbank", },
>  	{ .compatible = "calxeda,ecx-2000", },
>  
> +	{ .compatible = "fsl,imx8mq", },
> +	{ .compatible = "fsl,imx8mm", },
> +
>  	{ .compatible = "marvell,armadaxp", },
>  
>  	{ .compatible = "mediatek,mt2701", },
>  	{ .compatible = "mediatek,mt2712", },
>  	{ .compatible = "mediatek,mt7622", },
> diff --git a/drivers/cpufreq/imx-cpufreq-dt.c b/drivers/cpufreq/imx-cpufreq-dt.c
> new file mode 100644
> index 000000000000..9b2ee96c9213
> --- /dev/null
> +++ b/drivers/cpufreq/imx-cpufreq-dt.c
> @@ -0,0 +1,99 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright 2019 NXP
> + */
> +
> +#include <linux/cpu.h>
> +#include <linux/err.h>
> +#include <linux/init.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/nvmem-consumer.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/pm_opp.h>
> +#include <linux/slab.h>
> +
> +#define OCOTP_CFG3_SPEED_GRADE_SHIFT	8
> +#define OCOTP_CFG3_SPEED_GRADE_MASK	(0x3 << 8)
> +
> +static const struct of_device_id imx_cpufreq_dt_match_list[] = {
> +	{ .compatible = "fsl,imx8mm" },
> +	{ .compatible = "fsl,imx8mq" },
> +	{}
> +};
> +
> +static const struct of_device_id *imx_cpufreq_dt_match_node(void)
> +{
> +	struct device_node *np;
> +	const struct of_device_id *match;
> +
> +	np = of_find_node_by_path("/");
> +	match = of_match_node(imx_cpufreq_dt_match_list, np);
> +	of_node_put(np);
> +
> +	return match;
> +}
> +
> +/* cpufreq-dt device registered by imx-cpufreq-dt */
> +static struct platform_device *cpufreq_dt_pdev;
> +static struct opp_table *cpufreq_opp_table;
> +
> +static int imx_cpufreq_dt_probe(struct platform_device *pdev)
> +{
> +	struct device *cpu_dev = get_cpu_device(0);
> +	const struct of_device_id *match;
> +	u32 speed_grade;
> +	int ret;
> +
> +	match = imx_cpufreq_dt_match_node();

Just open code it here.

> +	if (!match)
> +		return -ENODEV;
> +
> +	ret = nvmem_cell_read_u32(cpu_dev, "speed_grade", &speed_grade);
> +	if (ret)
> +		return ret;
> +
> +	speed_grade = (speed_grade & OCOTP_CFG3_SPEED_GRADE_MASK) >> OCOTP_CFG3_SPEED_GRADE_SHIFT;
> +	dev_info(&pdev->dev, "cpu speed grade %d\n", speed_grade);
> +	speed_grade = 1 << speed_grade;
> +
> +	cpufreq_opp_table = dev_pm_opp_set_supported_hw(cpu_dev, &speed_grade, 1);
> +	if (IS_ERR(cpufreq_opp_table)) {
> +		ret = PTR_ERR(cpufreq_opp_table);
> +		dev_err(&pdev->dev, "Failed to set supported opp: %d\n", ret);
> +		return ret;
> +	}
> +
> +	cpufreq_dt_pdev = platform_device_register_data(
> +			&pdev->dev, "cpufreq-dt", -1, NULL, 0);
> +	if (IS_ERR(cpufreq_dt_pdev)) {
> +		dev_pm_opp_put_supported_hw(cpufreq_opp_table);
> +		ret = PTR_ERR(cpufreq_dt_pdev);
> +		dev_err(&pdev->dev, "Failed to register cpufreq-dt: %d\n", ret);
> +		return ret;
> +	}
> +
> +	return 0;
> +}
> +
> +static int imx_cpufreq_dt_remove(struct platform_device *pdev)
> +{
> +	platform_device_unregister(cpufreq_dt_pdev);
> +	dev_pm_opp_put_supported_hw(cpufreq_opp_table);
> +
> +	return 0;
> +}
> +
> +static struct platform_driver imx_cpufreq_dt_driver = {
> +	.probe = imx_cpufreq_dt_probe,
> +	.remove = imx_cpufreq_dt_remove,
> +	.driver = {
> +		.name = "imx-cpufreq-dt",
> +	},
> +};
> +module_platform_driver(imx_cpufreq_dt_driver);

Why add another virtual device-driver pair here? The only reason why we have
been adding it was to get deferred probe to work which doesn't look like the
case for this driver. Why not do everything from the init() routine ?

> +
> +MODULE_ALIAS("platform:imx-cpufreq-dt");
> +MODULE_DESCRIPTION("Freescale i.MX cpufreq speed grading driver");
> +MODULE_LICENSE("GPL v2");
> diff --git a/drivers/soc/imx/soc-imx8.c b/drivers/soc/imx/soc-imx8.c
> index cd10726e64e4..02988bdfbb73 100644
> --- a/drivers/soc/imx/soc-imx8.c
> +++ b/drivers/soc/imx/soc-imx8.c
> @@ -130,10 +130,13 @@ static int __init imx8_soc_init(void)
>  
>  	soc_dev = soc_device_register(soc_dev_attr);
>  	if (IS_ERR(soc_dev))
>  		goto free_rev;
>  
> +	if (IS_ENABLED(CONFIG_ARM_IMX_CPUFREQ_DT))
> +		platform_device_register_simple("imx-cpufreq-dt", -1, NULL, 0);
> +
>  	return 0;
>  
>  free_rev:
>  	kfree(soc_dev_attr->revision);
>  free_soc:
> -- 
> 2.17.1
> 

-- 
viresh

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH v2 1/3] cpufreq: Add imx-cpufreq-dt driver
@ 2019-05-03  6:52     ` Viresh Kumar
  0 siblings, 0 replies; 36+ messages in thread
From: Viresh Kumar @ 2019-05-03  6:52 UTC (permalink / raw)
  To: Leonard Crestez
  Cc: Aisheng Dong, Abel Vesa, Anson Huang, linux-pm,
	Rafael J. Wysocki, dl-linux-imx, kernel, Fabio Estevam,
	Lucas Stach, Shawn Guo, linux-arm-kernel, Jacky Bai

On 02-05-19, 22:44, Leonard Crestez wrote:
> Right now in upstream imx8m cpufreq support just lists a common subset
> of OPPs because the higher ones should only be attempted after checking
> speed grading in fuses.
> 
> Add a small driver which checks speed grading from nvmem cells before
> registering cpufreq-dt.
> 
> This allows unlocking all frequencies for imx8mm and imx8mq.
> 
> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
> 
> ---
>  drivers/cpufreq/Kconfig.arm          | 10 +++
>  drivers/cpufreq/Makefile             |  1 +
>  drivers/cpufreq/cpufreq-dt-platdev.c |  3 +
>  drivers/cpufreq/imx-cpufreq-dt.c     | 99 ++++++++++++++++++++++++++++
>  drivers/soc/imx/soc-imx8.c           |  3 +
>  5 files changed, 116 insertions(+)
>  create mode 100644 drivers/cpufreq/imx-cpufreq-dt.c
> 
> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> index 179a1d302f48..f8e40429e290 100644
> --- a/drivers/cpufreq/Kconfig.arm
> +++ b/drivers/cpufreq/Kconfig.arm
> @@ -90,10 +90,20 @@ config ARM_IMX6Q_CPUFREQ
>  	help
>  	  This adds cpufreq driver support for Freescale i.MX6 series SoCs.
>  
>  	  If in doubt, say N.
>  
> +config ARM_IMX_CPUFREQ_DT
> +	tristate "Freescale i.MX8M cpufreq support"
> +	depends on ARCH_MXC && CPUFREQ_DT
> +	default m if (ARCH_MXC && CPUFREQ_DT)

The if () part looks redundant here, why do you need it ?

> +	help
> +	  This adds cpufreq driver support for newer Freescale i.MX series

"newer" is a relative thing, it won't be newer an year or two later. Just drop
it.

> +	  SoCs, based on cpufreq-dt

Full stop (.) missing.

> +
> +	  If in doubt, say N.
> +
>  config ARM_KIRKWOOD_CPUFREQ
>  	def_bool MACH_KIRKWOOD
>  	help
>  	  This adds the CPUFreq driver for Marvell Kirkwood
>  	  SoCs.
> diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
> index 689b26c6f949..7bcda2273d0c 100644
> --- a/drivers/cpufreq/Makefile
> +++ b/drivers/cpufreq/Makefile
> @@ -54,10 +54,11 @@ obj-$(CONFIG_ARM_ARMADA_8K_CPUFREQ)	+= armada-8k-cpufreq.o
>  obj-$(CONFIG_ARM_BRCMSTB_AVS_CPUFREQ)	+= brcmstb-avs-cpufreq.o
>  obj-$(CONFIG_ACPI_CPPC_CPUFREQ)		+= cppc_cpufreq.o
>  obj-$(CONFIG_ARCH_DAVINCI)		+= davinci-cpufreq.o
>  obj-$(CONFIG_ARM_HIGHBANK_CPUFREQ)	+= highbank-cpufreq.o
>  obj-$(CONFIG_ARM_IMX6Q_CPUFREQ)		+= imx6q-cpufreq.o
> +obj-$(CONFIG_ARM_IMX_CPUFREQ_DT)	+= imx-cpufreq-dt.o
>  obj-$(CONFIG_ARM_KIRKWOOD_CPUFREQ)	+= kirkwood-cpufreq.o
>  obj-$(CONFIG_ARM_MEDIATEK_CPUFREQ)	+= mediatek-cpufreq.o
>  obj-$(CONFIG_MACH_MVEBU_V7)		+= mvebu-cpufreq.o
>  obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ)	+= omap-cpufreq.o
>  obj-$(CONFIG_ARM_PXA2xx_CPUFREQ)	+= pxa2xx-cpufreq.o
> diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
> index 47729a22c159..19c1aad57e26 100644
> --- a/drivers/cpufreq/cpufreq-dt-platdev.c
> +++ b/drivers/cpufreq/cpufreq-dt-platdev.c
> @@ -106,10 +106,13 @@ static const struct of_device_id whitelist[] __initconst = {
>   */
>  static const struct of_device_id blacklist[] __initconst = {
>  	{ .compatible = "calxeda,highbank", },
>  	{ .compatible = "calxeda,ecx-2000", },
>  
> +	{ .compatible = "fsl,imx8mq", },
> +	{ .compatible = "fsl,imx8mm", },
> +
>  	{ .compatible = "marvell,armadaxp", },
>  
>  	{ .compatible = "mediatek,mt2701", },
>  	{ .compatible = "mediatek,mt2712", },
>  	{ .compatible = "mediatek,mt7622", },
> diff --git a/drivers/cpufreq/imx-cpufreq-dt.c b/drivers/cpufreq/imx-cpufreq-dt.c
> new file mode 100644
> index 000000000000..9b2ee96c9213
> --- /dev/null
> +++ b/drivers/cpufreq/imx-cpufreq-dt.c
> @@ -0,0 +1,99 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright 2019 NXP
> + */
> +
> +#include <linux/cpu.h>
> +#include <linux/err.h>
> +#include <linux/init.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/nvmem-consumer.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/pm_opp.h>
> +#include <linux/slab.h>
> +
> +#define OCOTP_CFG3_SPEED_GRADE_SHIFT	8
> +#define OCOTP_CFG3_SPEED_GRADE_MASK	(0x3 << 8)
> +
> +static const struct of_device_id imx_cpufreq_dt_match_list[] = {
> +	{ .compatible = "fsl,imx8mm" },
> +	{ .compatible = "fsl,imx8mq" },
> +	{}
> +};
> +
> +static const struct of_device_id *imx_cpufreq_dt_match_node(void)
> +{
> +	struct device_node *np;
> +	const struct of_device_id *match;
> +
> +	np = of_find_node_by_path("/");
> +	match = of_match_node(imx_cpufreq_dt_match_list, np);
> +	of_node_put(np);
> +
> +	return match;
> +}
> +
> +/* cpufreq-dt device registered by imx-cpufreq-dt */
> +static struct platform_device *cpufreq_dt_pdev;
> +static struct opp_table *cpufreq_opp_table;
> +
> +static int imx_cpufreq_dt_probe(struct platform_device *pdev)
> +{
> +	struct device *cpu_dev = get_cpu_device(0);
> +	const struct of_device_id *match;
> +	u32 speed_grade;
> +	int ret;
> +
> +	match = imx_cpufreq_dt_match_node();

Just open code it here.

> +	if (!match)
> +		return -ENODEV;
> +
> +	ret = nvmem_cell_read_u32(cpu_dev, "speed_grade", &speed_grade);
> +	if (ret)
> +		return ret;
> +
> +	speed_grade = (speed_grade & OCOTP_CFG3_SPEED_GRADE_MASK) >> OCOTP_CFG3_SPEED_GRADE_SHIFT;
> +	dev_info(&pdev->dev, "cpu speed grade %d\n", speed_grade);
> +	speed_grade = 1 << speed_grade;
> +
> +	cpufreq_opp_table = dev_pm_opp_set_supported_hw(cpu_dev, &speed_grade, 1);
> +	if (IS_ERR(cpufreq_opp_table)) {
> +		ret = PTR_ERR(cpufreq_opp_table);
> +		dev_err(&pdev->dev, "Failed to set supported opp: %d\n", ret);
> +		return ret;
> +	}
> +
> +	cpufreq_dt_pdev = platform_device_register_data(
> +			&pdev->dev, "cpufreq-dt", -1, NULL, 0);
> +	if (IS_ERR(cpufreq_dt_pdev)) {
> +		dev_pm_opp_put_supported_hw(cpufreq_opp_table);
> +		ret = PTR_ERR(cpufreq_dt_pdev);
> +		dev_err(&pdev->dev, "Failed to register cpufreq-dt: %d\n", ret);
> +		return ret;
> +	}
> +
> +	return 0;
> +}
> +
> +static int imx_cpufreq_dt_remove(struct platform_device *pdev)
> +{
> +	platform_device_unregister(cpufreq_dt_pdev);
> +	dev_pm_opp_put_supported_hw(cpufreq_opp_table);
> +
> +	return 0;
> +}
> +
> +static struct platform_driver imx_cpufreq_dt_driver = {
> +	.probe = imx_cpufreq_dt_probe,
> +	.remove = imx_cpufreq_dt_remove,
> +	.driver = {
> +		.name = "imx-cpufreq-dt",
> +	},
> +};
> +module_platform_driver(imx_cpufreq_dt_driver);

Why add another virtual device-driver pair here? The only reason why we have
been adding it was to get deferred probe to work which doesn't look like the
case for this driver. Why not do everything from the init() routine ?

> +
> +MODULE_ALIAS("platform:imx-cpufreq-dt");
> +MODULE_DESCRIPTION("Freescale i.MX cpufreq speed grading driver");
> +MODULE_LICENSE("GPL v2");
> diff --git a/drivers/soc/imx/soc-imx8.c b/drivers/soc/imx/soc-imx8.c
> index cd10726e64e4..02988bdfbb73 100644
> --- a/drivers/soc/imx/soc-imx8.c
> +++ b/drivers/soc/imx/soc-imx8.c
> @@ -130,10 +130,13 @@ static int __init imx8_soc_init(void)
>  
>  	soc_dev = soc_device_register(soc_dev_attr);
>  	if (IS_ERR(soc_dev))
>  		goto free_rev;
>  
> +	if (IS_ENABLED(CONFIG_ARM_IMX_CPUFREQ_DT))
> +		platform_device_register_simple("imx-cpufreq-dt", -1, NULL, 0);
> +
>  	return 0;
>  
>  free_rev:
>  	kfree(soc_dev_attr->revision);
>  free_soc:
> -- 
> 2.17.1
> 

-- 
viresh

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

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH v2 2/3] arm64: dts: imx8mm: Add cpu speed grading and all OPPs
@ 2019-05-03  6:52     ` Viresh Kumar
  0 siblings, 0 replies; 36+ messages in thread
From: Viresh Kumar @ 2019-05-03  6:52 UTC (permalink / raw)
  To: Leonard Crestez
  Cc: Aisheng Dong, Abel Vesa, Anson Huang, linux-pm,
	Rafael J. Wysocki, dl-linux-imx, kernel, Fabio Estevam,
	Lucas Stach, Shawn Guo, linux-arm-kernel, Jacky Bai

On 02-05-19, 22:44, Leonard Crestez wrote:
> Add a nvmem cell on cpu node referencing speed grade and the 1.8 Ghz
> cpufreq opp.
> 
> The imx-cpufreq-dt driver will read speed grade and disable higher opps
> if unsupported.
> 
> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
> ---
>  arch/arm64/boot/dts/freescale/imx8mm.dtsi | 23 ++++++++++++++++++++++-
>  1 file changed, 22 insertions(+), 1 deletion(-)

Acked-by: Viresh Kumar <viresh.kumar@linaro.org>

-- 
viresh

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH v2 2/3] arm64: dts: imx8mm: Add cpu speed grading and all OPPs
@ 2019-05-03  6:52     ` Viresh Kumar
  0 siblings, 0 replies; 36+ messages in thread
From: Viresh Kumar @ 2019-05-03  6:52 UTC (permalink / raw)
  To: Leonard Crestez
  Cc: Lucas Stach, Shawn Guo, Rafael J. Wysocki, Anson Huang,
	Jacky Bai, Abel Vesa, Aisheng Dong, Fabio Estevam, linux-pm,
	kernel, dl-linux-imx, linux-arm-kernel

On 02-05-19, 22:44, Leonard Crestez wrote:
> Add a nvmem cell on cpu node referencing speed grade and the 1.8 Ghz
> cpufreq opp.
> 
> The imx-cpufreq-dt driver will read speed grade and disable higher opps
> if unsupported.
> 
> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
> ---
>  arch/arm64/boot/dts/freescale/imx8mm.dtsi | 23 ++++++++++++++++++++++-
>  1 file changed, 22 insertions(+), 1 deletion(-)

Acked-by: Viresh Kumar <viresh.kumar@linaro.org>

-- 
viresh

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH v2 2/3] arm64: dts: imx8mm: Add cpu speed grading and all OPPs
@ 2019-05-03  6:52     ` Viresh Kumar
  0 siblings, 0 replies; 36+ messages in thread
From: Viresh Kumar @ 2019-05-03  6:52 UTC (permalink / raw)
  To: Leonard Crestez
  Cc: Aisheng Dong, Abel Vesa, Anson Huang, linux-pm,
	Rafael J. Wysocki, dl-linux-imx, kernel, Fabio Estevam,
	Lucas Stach, Shawn Guo, linux-arm-kernel, Jacky Bai

On 02-05-19, 22:44, Leonard Crestez wrote:
> Add a nvmem cell on cpu node referencing speed grade and the 1.8 Ghz
> cpufreq opp.
> 
> The imx-cpufreq-dt driver will read speed grade and disable higher opps
> if unsupported.
> 
> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
> ---
>  arch/arm64/boot/dts/freescale/imx8mm.dtsi | 23 ++++++++++++++++++++++-
>  1 file changed, 22 insertions(+), 1 deletion(-)

Acked-by: Viresh Kumar <viresh.kumar@linaro.org>

-- 
viresh

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

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH v2 3/3] arm64: dts: imx8mq: Add cpu speed grading and all OPPs
@ 2019-05-03  6:53     ` Viresh Kumar
  0 siblings, 0 replies; 36+ messages in thread
From: Viresh Kumar @ 2019-05-03  6:53 UTC (permalink / raw)
  To: Leonard Crestez
  Cc: Aisheng Dong, Abel Vesa, Anson Huang, linux-pm,
	Rafael J. Wysocki, dl-linux-imx, kernel, Fabio Estevam,
	Lucas Stach, Shawn Guo, linux-arm-kernel, Jacky Bai

On 02-05-19, 22:44, Leonard Crestez wrote:
> Add nvmem-cells reference to cpu and fill the OPP table with all known
> OPPs.
> 
> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
> ---
>  arch/arm64/boot/dts/freescale/imx8mq.dtsi | 23 ++++++++++++++++++++++-
>  1 file changed, 22 insertions(+), 1 deletion(-)

Acked-by: Viresh Kumar <viresh.kumar@linaro.org>

-- 
viresh

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH v2 3/3] arm64: dts: imx8mq: Add cpu speed grading and all OPPs
@ 2019-05-03  6:53     ` Viresh Kumar
  0 siblings, 0 replies; 36+ messages in thread
From: Viresh Kumar @ 2019-05-03  6:53 UTC (permalink / raw)
  To: Leonard Crestez
  Cc: Lucas Stach, Shawn Guo, Rafael J. Wysocki, Anson Huang,
	Jacky Bai, Abel Vesa, Aisheng Dong, Fabio Estevam, linux-pm,
	kernel, dl-linux-imx, linux-arm-kernel

On 02-05-19, 22:44, Leonard Crestez wrote:
> Add nvmem-cells reference to cpu and fill the OPP table with all known
> OPPs.
> 
> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
> ---
>  arch/arm64/boot/dts/freescale/imx8mq.dtsi | 23 ++++++++++++++++++++++-
>  1 file changed, 22 insertions(+), 1 deletion(-)

Acked-by: Viresh Kumar <viresh.kumar@linaro.org>

-- 
viresh

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH v2 3/3] arm64: dts: imx8mq: Add cpu speed grading and all OPPs
@ 2019-05-03  6:53     ` Viresh Kumar
  0 siblings, 0 replies; 36+ messages in thread
From: Viresh Kumar @ 2019-05-03  6:53 UTC (permalink / raw)
  To: Leonard Crestez
  Cc: Aisheng Dong, Abel Vesa, Anson Huang, linux-pm,
	Rafael J. Wysocki, dl-linux-imx, kernel, Fabio Estevam,
	Lucas Stach, Shawn Guo, linux-arm-kernel, Jacky Bai

On 02-05-19, 22:44, Leonard Crestez wrote:
> Add nvmem-cells reference to cpu and fill the OPP table with all known
> OPPs.
> 
> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
> ---
>  arch/arm64/boot/dts/freescale/imx8mq.dtsi | 23 ++++++++++++++++++++++-
>  1 file changed, 22 insertions(+), 1 deletion(-)

Acked-by: Viresh Kumar <viresh.kumar@linaro.org>

-- 
viresh

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

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH v2 1/3] cpufreq: Add imx-cpufreq-dt driver
@ 2019-05-03  9:44       ` Leonard Crestez
  0 siblings, 0 replies; 36+ messages in thread
From: Leonard Crestez @ 2019-05-03  9:44 UTC (permalink / raw)
  To: Viresh Kumar
  Cc: Aisheng Dong, Abel Vesa, Anson Huang, linux-pm,
	Rafael J. Wysocki, dl-linux-imx, kernel, Fabio Estevam,
	Lucas Stach, Shawn Guo, linux-arm-kernel, Jacky Bai

On 03.05.2019 09:52, Viresh Kumar wrote:
> On 02-05-19, 22:44, Leonard Crestez wrote:
>> Right now in upstream imx8m cpufreq support just lists a common subset
>> of OPPs because the higher ones should only be attempted after checking
>> speed grading in fuses.
>>
>> Add a small driver which checks speed grading from nvmem cells before
>> registering cpufreq-dt.
>>
>> This allows unlocking all frequencies for imx8mm and imx8mq.
>>
>> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
>> @@ -90,10 +90,20 @@ config ARM_IMX6Q_CPUFREQ
>>   	help
>>   	  This adds cpufreq driver support for Freescale i.MX6 series SoCs.
>>   
>>   	  If in doubt, say N.
>>   
>> +config ARM_IMX_CPUFREQ_DT
>> +	tristate "Freescale i.MX8M cpufreq support"
>> +	depends on ARCH_MXC && CPUFREQ_DT
>> +	default m if (ARCH_MXC && CPUFREQ_DT)
>> +	help
>> +	  This adds cpufreq driver support for newer Freescale i.MX series
> 
> "newer" is a relative thing, it won't be newer an year or two later. Just drop
> it.

I meant "newer than i.MX6". Various attempts at adding explicit cpufreq 
drivers for newer SOCs were rejected in favor of cpufreq-dt.

I'll change to mention i.MX8M explicitly and update if 7 is added.

>> +static struct platform_driver imx_cpufreq_dt_driver = {
>> +	.probe = imx_cpufreq_dt_probe,
>> +	.remove = imx_cpufreq_dt_remove,
>> +	.driver = {
>> +		.name = "imx-cpufreq-dt",
>> +	},
>> +};
>> +module_platform_driver(imx_cpufreq_dt_driver);
> 
> Why add another virtual device-driver pair here? The only reason why we have
> been adding it was to get deferred probe to work which doesn't look like the
> case for this driver. Why not do everything from the init() routine ?

The imx-cpufreq-dt platform_driver reads from fuses (nvmem/imx-ocotp) 
which can be theoretically be built as a module and also has clock 
requirements. No sure we should rely that the call to read from nvmem 
never returns EPROBE_DEFER.

I'm not sure which "init()" you mean, the registration code is inside 
soc driver and at that point the fuse driver might not be available.

--
Regards,
Leonard

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH v2 1/3] cpufreq: Add imx-cpufreq-dt driver
@ 2019-05-03  9:44       ` Leonard Crestez
  0 siblings, 0 replies; 36+ messages in thread
From: Leonard Crestez @ 2019-05-03  9:44 UTC (permalink / raw)
  To: Viresh Kumar
  Cc: Lucas Stach, Shawn Guo, Rafael J. Wysocki, Anson Huang,
	Jacky Bai, Abel Vesa, Aisheng Dong, Fabio Estevam, linux-pm,
	kernel, dl-linux-imx, linux-arm-kernel

On 03.05.2019 09:52, Viresh Kumar wrote:
> On 02-05-19, 22:44, Leonard Crestez wrote:
>> Right now in upstream imx8m cpufreq support just lists a common subset
>> of OPPs because the higher ones should only be attempted after checking
>> speed grading in fuses.
>>
>> Add a small driver which checks speed grading from nvmem cells before
>> registering cpufreq-dt.
>>
>> This allows unlocking all frequencies for imx8mm and imx8mq.
>>
>> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
>> @@ -90,10 +90,20 @@ config ARM_IMX6Q_CPUFREQ
>>   	help
>>   	  This adds cpufreq driver support for Freescale i.MX6 series SoCs.
>>   
>>   	  If in doubt, say N.
>>   
>> +config ARM_IMX_CPUFREQ_DT
>> +	tristate "Freescale i.MX8M cpufreq support"
>> +	depends on ARCH_MXC && CPUFREQ_DT
>> +	default m if (ARCH_MXC && CPUFREQ_DT)
>> +	help
>> +	  This adds cpufreq driver support for newer Freescale i.MX series
> 
> "newer" is a relative thing, it won't be newer an year or two later. Just drop
> it.

I meant "newer than i.MX6". Various attempts at adding explicit cpufreq 
drivers for newer SOCs were rejected in favor of cpufreq-dt.

I'll change to mention i.MX8M explicitly and update if 7 is added.

>> +static struct platform_driver imx_cpufreq_dt_driver = {
>> +	.probe = imx_cpufreq_dt_probe,
>> +	.remove = imx_cpufreq_dt_remove,
>> +	.driver = {
>> +		.name = "imx-cpufreq-dt",
>> +	},
>> +};
>> +module_platform_driver(imx_cpufreq_dt_driver);
> 
> Why add another virtual device-driver pair here? The only reason why we have
> been adding it was to get deferred probe to work which doesn't look like the
> case for this driver. Why not do everything from the init() routine ?

The imx-cpufreq-dt platform_driver reads from fuses (nvmem/imx-ocotp) 
which can be theoretically be built as a module and also has clock 
requirements. No sure we should rely that the call to read from nvmem 
never returns EPROBE_DEFER.

I'm not sure which "init()" you mean, the registration code is inside 
soc driver and at that point the fuse driver might not be available.

--
Regards,
Leonard

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH v2 1/3] cpufreq: Add imx-cpufreq-dt driver
@ 2019-05-03  9:44       ` Leonard Crestez
  0 siblings, 0 replies; 36+ messages in thread
From: Leonard Crestez @ 2019-05-03  9:44 UTC (permalink / raw)
  To: Viresh Kumar
  Cc: Aisheng Dong, Abel Vesa, Anson Huang, linux-pm,
	Rafael J. Wysocki, dl-linux-imx, kernel, Fabio Estevam,
	Lucas Stach, Shawn Guo, linux-arm-kernel, Jacky Bai

On 03.05.2019 09:52, Viresh Kumar wrote:
> On 02-05-19, 22:44, Leonard Crestez wrote:
>> Right now in upstream imx8m cpufreq support just lists a common subset
>> of OPPs because the higher ones should only be attempted after checking
>> speed grading in fuses.
>>
>> Add a small driver which checks speed grading from nvmem cells before
>> registering cpufreq-dt.
>>
>> This allows unlocking all frequencies for imx8mm and imx8mq.
>>
>> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
>> @@ -90,10 +90,20 @@ config ARM_IMX6Q_CPUFREQ
>>   	help
>>   	  This adds cpufreq driver support for Freescale i.MX6 series SoCs.
>>   
>>   	  If in doubt, say N.
>>   
>> +config ARM_IMX_CPUFREQ_DT
>> +	tristate "Freescale i.MX8M cpufreq support"
>> +	depends on ARCH_MXC && CPUFREQ_DT
>> +	default m if (ARCH_MXC && CPUFREQ_DT)
>> +	help
>> +	  This adds cpufreq driver support for newer Freescale i.MX series
> 
> "newer" is a relative thing, it won't be newer an year or two later. Just drop
> it.

I meant "newer than i.MX6". Various attempts at adding explicit cpufreq 
drivers for newer SOCs were rejected in favor of cpufreq-dt.

I'll change to mention i.MX8M explicitly and update if 7 is added.

>> +static struct platform_driver imx_cpufreq_dt_driver = {
>> +	.probe = imx_cpufreq_dt_probe,
>> +	.remove = imx_cpufreq_dt_remove,
>> +	.driver = {
>> +		.name = "imx-cpufreq-dt",
>> +	},
>> +};
>> +module_platform_driver(imx_cpufreq_dt_driver);
> 
> Why add another virtual device-driver pair here? The only reason why we have
> been adding it was to get deferred probe to work which doesn't look like the
> case for this driver. Why not do everything from the init() routine ?

The imx-cpufreq-dt platform_driver reads from fuses (nvmem/imx-ocotp) 
which can be theoretically be built as a module and also has clock 
requirements. No sure we should rely that the call to read from nvmem 
never returns EPROBE_DEFER.

I'm not sure which "init()" you mean, the registration code is inside 
soc driver and at that point the fuse driver might not be available.

--
Regards,
Leonard

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

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH v2 1/3] cpufreq: Add imx-cpufreq-dt driver
@ 2019-05-03  9:53         ` Viresh Kumar
  0 siblings, 0 replies; 36+ messages in thread
From: Viresh Kumar @ 2019-05-03  9:53 UTC (permalink / raw)
  To: Leonard Crestez
  Cc: Aisheng Dong, Abel Vesa, Anson Huang, linux-pm,
	Rafael J. Wysocki, dl-linux-imx, kernel, Fabio Estevam,
	Lucas Stach, Shawn Guo, linux-arm-kernel, Jacky Bai

On 03-05-19, 09:44, Leonard Crestez wrote:
> On 03.05.2019 09:52, Viresh Kumar wrote:

> > Why add another virtual device-driver pair here? The only reason why we have
> > been adding it was to get deferred probe to work which doesn't look like the
> > case for this driver. Why not do everything from the init() routine ?
> 
> The imx-cpufreq-dt platform_driver reads from fuses (nvmem/imx-ocotp) 
> which can be theoretically be built as a module and also has clock 

I am not against making this driver a module, that is okay.

> requirements. No sure we should rely that the call to read from nvmem 
> never returns EPROBE_DEFER.

Okay, I didn't realize that we can get EPROBE_DEFER from
nvmem_cell_read_u32(). Should be fine then.

-- 
viresh

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH v2 1/3] cpufreq: Add imx-cpufreq-dt driver
@ 2019-05-03  9:53         ` Viresh Kumar
  0 siblings, 0 replies; 36+ messages in thread
From: Viresh Kumar @ 2019-05-03  9:53 UTC (permalink / raw)
  To: Leonard Crestez
  Cc: Lucas Stach, Shawn Guo, Rafael J. Wysocki, Anson Huang,
	Jacky Bai, Abel Vesa, Aisheng Dong, Fabio Estevam, linux-pm,
	kernel, dl-linux-imx, linux-arm-kernel

On 03-05-19, 09:44, Leonard Crestez wrote:
> On 03.05.2019 09:52, Viresh Kumar wrote:

> > Why add another virtual device-driver pair here? The only reason why we have
> > been adding it was to get deferred probe to work which doesn't look like the
> > case for this driver. Why not do everything from the init() routine ?
> 
> The imx-cpufreq-dt platform_driver reads from fuses (nvmem/imx-ocotp) 
> which can be theoretically be built as a module and also has clock 

I am not against making this driver a module, that is okay.

> requirements. No sure we should rely that the call to read from nvmem 
> never returns EPROBE_DEFER.

Okay, I didn't realize that we can get EPROBE_DEFER from
nvmem_cell_read_u32(). Should be fine then.

-- 
viresh

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH v2 1/3] cpufreq: Add imx-cpufreq-dt driver
@ 2019-05-03  9:53         ` Viresh Kumar
  0 siblings, 0 replies; 36+ messages in thread
From: Viresh Kumar @ 2019-05-03  9:53 UTC (permalink / raw)
  To: Leonard Crestez
  Cc: Aisheng Dong, Abel Vesa, Anson Huang, linux-pm,
	Rafael J. Wysocki, dl-linux-imx, kernel, Fabio Estevam,
	Lucas Stach, Shawn Guo, linux-arm-kernel, Jacky Bai

On 03-05-19, 09:44, Leonard Crestez wrote:
> On 03.05.2019 09:52, Viresh Kumar wrote:

> > Why add another virtual device-driver pair here? The only reason why we have
> > been adding it was to get deferred probe to work which doesn't look like the
> > case for this driver. Why not do everything from the init() routine ?
> 
> The imx-cpufreq-dt platform_driver reads from fuses (nvmem/imx-ocotp) 
> which can be theoretically be built as a module and also has clock 

I am not against making this driver a module, that is okay.

> requirements. No sure we should rely that the call to read from nvmem 
> never returns EPROBE_DEFER.

Okay, I didn't realize that we can get EPROBE_DEFER from
nvmem_cell_read_u32(). Should be fine then.

-- 
viresh

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

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH v2 0/3] cpufreq: Add imx-cpufreq-dt driver
@ 2019-05-03 11:51     ` Leonard Crestez
  0 siblings, 0 replies; 36+ messages in thread
From: Leonard Crestez @ 2019-05-03 11:51 UTC (permalink / raw)
  To: Viresh Kumar
  Cc: Aisheng Dong, Abel Vesa, Anson Huang, linux-pm,
	Rafael J. Wysocki, dl-linux-imx, kernel, Fabio Estevam,
	Lucas Stach, Shawn Guo, linux-arm-kernel, Jacky Bai

On 03.05.2019 09:50, Viresh Kumar wrote:
> On 02-05-19, 22:44, Leonard Crestez wrote:
>> Right now in upstream imx8m cpufreq support just lists a common subset
>> of OPPs because the higher ones should only be attempted after checking
>> speed grading in fuses.
>>
>> Add a small driver which checks speed grading from nvmem cells before
>> registering cpufreq-dt.
>>
>> It seems that cpufreq-dt insists on adding the opp and regulator itself
>> so can't actually call dev_pm_opp_of_add_table and then
>> dev_pm_opp_disable
> 
> Well we can surely implement it someway if that is what you want, like we can
> pass postinit() callback in platform data to cpufreq-dt which can get called
> after OPP table is added, etc.
> 
> But disabling OPPs after they are added isn't a great way of handling it as
> well.
> 
>> so implementation was switched to opp-supported-hw.
> 
> I will say that this is far better than disabling the OPPs after adding them. So
> this is a good way of doing it.

The intention seems to be that dev_pm_opp_disable is used at run-time 
for stuff like thermal issues while init-time opp selection should be 
done in other ways.

Is this what you mean? It's not very obvious from API.

--
Regards,
Leonard

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH v2 0/3] cpufreq: Add imx-cpufreq-dt driver
@ 2019-05-03 11:51     ` Leonard Crestez
  0 siblings, 0 replies; 36+ messages in thread
From: Leonard Crestez @ 2019-05-03 11:51 UTC (permalink / raw)
  To: Viresh Kumar
  Cc: Lucas Stach, Shawn Guo, Rafael J. Wysocki, Anson Huang,
	Jacky Bai, Abel Vesa, Aisheng Dong, Fabio Estevam, linux-pm,
	kernel, dl-linux-imx, linux-arm-kernel

On 03.05.2019 09:50, Viresh Kumar wrote:
> On 02-05-19, 22:44, Leonard Crestez wrote:
>> Right now in upstream imx8m cpufreq support just lists a common subset
>> of OPPs because the higher ones should only be attempted after checking
>> speed grading in fuses.
>>
>> Add a small driver which checks speed grading from nvmem cells before
>> registering cpufreq-dt.
>>
>> It seems that cpufreq-dt insists on adding the opp and regulator itself
>> so can't actually call dev_pm_opp_of_add_table and then
>> dev_pm_opp_disable
> 
> Well we can surely implement it someway if that is what you want, like we can
> pass postinit() callback in platform data to cpufreq-dt which can get called
> after OPP table is added, etc.
> 
> But disabling OPPs after they are added isn't a great way of handling it as
> well.
> 
>> so implementation was switched to opp-supported-hw.
> 
> I will say that this is far better than disabling the OPPs after adding them. So
> this is a good way of doing it.

The intention seems to be that dev_pm_opp_disable is used at run-time 
for stuff like thermal issues while init-time opp selection should be 
done in other ways.

Is this what you mean? It's not very obvious from API.

--
Regards,
Leonard

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH v2 0/3] cpufreq: Add imx-cpufreq-dt driver
@ 2019-05-03 11:51     ` Leonard Crestez
  0 siblings, 0 replies; 36+ messages in thread
From: Leonard Crestez @ 2019-05-03 11:51 UTC (permalink / raw)
  To: Viresh Kumar
  Cc: Aisheng Dong, Abel Vesa, Anson Huang, linux-pm,
	Rafael J. Wysocki, dl-linux-imx, kernel, Fabio Estevam,
	Lucas Stach, Shawn Guo, linux-arm-kernel, Jacky Bai

On 03.05.2019 09:50, Viresh Kumar wrote:
> On 02-05-19, 22:44, Leonard Crestez wrote:
>> Right now in upstream imx8m cpufreq support just lists a common subset
>> of OPPs because the higher ones should only be attempted after checking
>> speed grading in fuses.
>>
>> Add a small driver which checks speed grading from nvmem cells before
>> registering cpufreq-dt.
>>
>> It seems that cpufreq-dt insists on adding the opp and regulator itself
>> so can't actually call dev_pm_opp_of_add_table and then
>> dev_pm_opp_disable
> 
> Well we can surely implement it someway if that is what you want, like we can
> pass postinit() callback in platform data to cpufreq-dt which can get called
> after OPP table is added, etc.
> 
> But disabling OPPs after they are added isn't a great way of handling it as
> well.
> 
>> so implementation was switched to opp-supported-hw.
> 
> I will say that this is far better than disabling the OPPs after adding them. So
> this is a good way of doing it.

The intention seems to be that dev_pm_opp_disable is used at run-time 
for stuff like thermal issues while init-time opp selection should be 
done in other ways.

Is this what you mean? It's not very obvious from API.

--
Regards,
Leonard

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

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH v2 0/3] cpufreq: Add imx-cpufreq-dt driver
@ 2019-05-07  5:35       ` Viresh Kumar
  0 siblings, 0 replies; 36+ messages in thread
From: Viresh Kumar @ 2019-05-07  5:35 UTC (permalink / raw)
  To: Leonard Crestez
  Cc: Aisheng Dong, Abel Vesa, Anson Huang, linux-pm,
	Rafael J. Wysocki, dl-linux-imx, kernel, Fabio Estevam,
	Lucas Stach, Shawn Guo, linux-arm-kernel, Jacky Bai

On 03-05-19, 11:51, Leonard Crestez wrote:
> On 03.05.2019 09:50, Viresh Kumar wrote:
> > On 02-05-19, 22:44, Leonard Crestez wrote:
> >> Right now in upstream imx8m cpufreq support just lists a common subset
> >> of OPPs because the higher ones should only be attempted after checking
> >> speed grading in fuses.
> >>
> >> Add a small driver which checks speed grading from nvmem cells before
> >> registering cpufreq-dt.
> >>
> >> It seems that cpufreq-dt insists on adding the opp and regulator itself
> >> so can't actually call dev_pm_opp_of_add_table and then
> >> dev_pm_opp_disable
> > 
> > Well we can surely implement it someway if that is what you want, like we can
> > pass postinit() callback in platform data to cpufreq-dt which can get called
> > after OPP table is added, etc.
> > 
> > But disabling OPPs after they are added isn't a great way of handling it as
> > well.
> > 
> >> so implementation was switched to opp-supported-hw.
> > 
> > I will say that this is far better than disabling the OPPs after adding them. So
> > this is a good way of doing it.
> 
> The intention seems to be that dev_pm_opp_disable is used at run-time 
> for stuff like thermal issues while init-time opp selection should be 
> done in other ways.
> 
> Is this what you mean? It's not very obvious from API.

Well there are no hard and fast rules for using the API and what I was
talking about was as to which API makes more sense. I am less in favor
of using dev_pm_opp_disable() here as we will make the OPP available
first on the platform and then disable it. What if the cpufreq core
gets a chance to run in between and program the OPP which isn't
allowed on the SoC ? That may cause problems, right ? And so disable
should be used for things which are getting used just fine and at some
point of time we decide to disable them.

-- 
viresh

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH v2 0/3] cpufreq: Add imx-cpufreq-dt driver
@ 2019-05-07  5:35       ` Viresh Kumar
  0 siblings, 0 replies; 36+ messages in thread
From: Viresh Kumar @ 2019-05-07  5:35 UTC (permalink / raw)
  To: Leonard Crestez
  Cc: Lucas Stach, Shawn Guo, Rafael J. Wysocki, Anson Huang,
	Jacky Bai, Abel Vesa, Aisheng Dong, Fabio Estevam, linux-pm,
	kernel, dl-linux-imx, linux-arm-kernel

On 03-05-19, 11:51, Leonard Crestez wrote:
> On 03.05.2019 09:50, Viresh Kumar wrote:
> > On 02-05-19, 22:44, Leonard Crestez wrote:
> >> Right now in upstream imx8m cpufreq support just lists a common subset
> >> of OPPs because the higher ones should only be attempted after checking
> >> speed grading in fuses.
> >>
> >> Add a small driver which checks speed grading from nvmem cells before
> >> registering cpufreq-dt.
> >>
> >> It seems that cpufreq-dt insists on adding the opp and regulator itself
> >> so can't actually call dev_pm_opp_of_add_table and then
> >> dev_pm_opp_disable
> > 
> > Well we can surely implement it someway if that is what you want, like we can
> > pass postinit() callback in platform data to cpufreq-dt which can get called
> > after OPP table is added, etc.
> > 
> > But disabling OPPs after they are added isn't a great way of handling it as
> > well.
> > 
> >> so implementation was switched to opp-supported-hw.
> > 
> > I will say that this is far better than disabling the OPPs after adding them. So
> > this is a good way of doing it.
> 
> The intention seems to be that dev_pm_opp_disable is used at run-time 
> for stuff like thermal issues while init-time opp selection should be 
> done in other ways.
> 
> Is this what you mean? It's not very obvious from API.

Well there are no hard and fast rules for using the API and what I was
talking about was as to which API makes more sense. I am less in favor
of using dev_pm_opp_disable() here as we will make the OPP available
first on the platform and then disable it. What if the cpufreq core
gets a chance to run in between and program the OPP which isn't
allowed on the SoC ? That may cause problems, right ? And so disable
should be used for things which are getting used just fine and at some
point of time we decide to disable them.

-- 
viresh

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH v2 0/3] cpufreq: Add imx-cpufreq-dt driver
@ 2019-05-07  5:35       ` Viresh Kumar
  0 siblings, 0 replies; 36+ messages in thread
From: Viresh Kumar @ 2019-05-07  5:35 UTC (permalink / raw)
  To: Leonard Crestez
  Cc: Aisheng Dong, Abel Vesa, Anson Huang, linux-pm,
	Rafael J. Wysocki, dl-linux-imx, kernel, Fabio Estevam,
	Lucas Stach, Shawn Guo, linux-arm-kernel, Jacky Bai

On 03-05-19, 11:51, Leonard Crestez wrote:
> On 03.05.2019 09:50, Viresh Kumar wrote:
> > On 02-05-19, 22:44, Leonard Crestez wrote:
> >> Right now in upstream imx8m cpufreq support just lists a common subset
> >> of OPPs because the higher ones should only be attempted after checking
> >> speed grading in fuses.
> >>
> >> Add a small driver which checks speed grading from nvmem cells before
> >> registering cpufreq-dt.
> >>
> >> It seems that cpufreq-dt insists on adding the opp and regulator itself
> >> so can't actually call dev_pm_opp_of_add_table and then
> >> dev_pm_opp_disable
> > 
> > Well we can surely implement it someway if that is what you want, like we can
> > pass postinit() callback in platform data to cpufreq-dt which can get called
> > after OPP table is added, etc.
> > 
> > But disabling OPPs after they are added isn't a great way of handling it as
> > well.
> > 
> >> so implementation was switched to opp-supported-hw.
> > 
> > I will say that this is far better than disabling the OPPs after adding them. So
> > this is a good way of doing it.
> 
> The intention seems to be that dev_pm_opp_disable is used at run-time 
> for stuff like thermal issues while init-time opp selection should be 
> done in other ways.
> 
> Is this what you mean? It's not very obvious from API.

Well there are no hard and fast rules for using the API and what I was
talking about was as to which API makes more sense. I am less in favor
of using dev_pm_opp_disable() here as we will make the OPP available
first on the platform and then disable it. What if the cpufreq core
gets a chance to run in between and program the OPP which isn't
allowed on the SoC ? That may cause problems, right ? And so disable
should be used for things which are getting used just fine and at some
point of time we decide to disable them.

-- 
viresh

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

^ permalink raw reply	[flat|nested] 36+ messages in thread

end of thread, other threads:[~2019-05-07  6:01 UTC | newest]

Thread overview: 36+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-05-02 22:44 [PATCH v2 0/3] cpufreq: Add imx-cpufreq-dt driver Leonard Crestez
2019-05-02 22:44 ` Leonard Crestez
2019-05-02 22:44 ` Leonard Crestez
2019-05-02 22:44 ` [PATCH v2 1/3] " Leonard Crestez
2019-05-02 22:44   ` Leonard Crestez
2019-05-02 22:44   ` Leonard Crestez
2019-05-03  6:52   ` Viresh Kumar
2019-05-03  6:52     ` Viresh Kumar
2019-05-03  6:52     ` Viresh Kumar
2019-05-03  9:44     ` Leonard Crestez
2019-05-03  9:44       ` Leonard Crestez
2019-05-03  9:44       ` Leonard Crestez
2019-05-03  9:53       ` Viresh Kumar
2019-05-03  9:53         ` Viresh Kumar
2019-05-03  9:53         ` Viresh Kumar
2019-05-02 22:44 ` [PATCH v2 2/3] arm64: dts: imx8mm: Add cpu speed grading and all OPPs Leonard Crestez
2019-05-02 22:44   ` Leonard Crestez
2019-05-02 22:44   ` Leonard Crestez
2019-05-03  6:52   ` Viresh Kumar
2019-05-03  6:52     ` Viresh Kumar
2019-05-03  6:52     ` Viresh Kumar
2019-05-02 22:44 ` [PATCH v2 3/3] arm64: dts: imx8mq: " Leonard Crestez
2019-05-02 22:44   ` Leonard Crestez
2019-05-02 22:44   ` Leonard Crestez
2019-05-03  6:53   ` Viresh Kumar
2019-05-03  6:53     ` Viresh Kumar
2019-05-03  6:53     ` Viresh Kumar
2019-05-03  6:50 ` [PATCH v2 0/3] cpufreq: Add imx-cpufreq-dt driver Viresh Kumar
2019-05-03  6:50   ` Viresh Kumar
2019-05-03  6:50   ` Viresh Kumar
2019-05-03 11:51   ` Leonard Crestez
2019-05-03 11:51     ` Leonard Crestez
2019-05-03 11:51     ` Leonard Crestez
2019-05-07  5:35     ` Viresh Kumar
2019-05-07  5:35       ` Viresh Kumar
2019-05-07  5:35       ` Viresh Kumar

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.