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. Driver reads from nvmem and calls dev_pm_opp_set_supported_hw before registering cpufreq-dt. Changes since v2: * Minor reformatting in Kconfig (Viresh) * Open-code imx_cpufreq_dt_match_node (Viresh) * Add mkt_segment bits to supported_hw and update .dtsi to match after reviewing latest datasheets. * Add dt-bindings like other opp-supported-hw users * Add devicetree mailing list (keep forgetting dts needs to be reviewed) Link to v2: https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=113163 Link to v1 (RFC): https://patchwork.kernel.org/patch/10916769/ I never noticed anything wrong with going above the fused speed grading however it's technically unsafe so the cpufreq code changes should go in before DT changes. Driver is module by default. It depends on nvmem-imx which can also be a module. It's a platform device registered from soc-imx8 because couldn't find any appropriate node for MODULE_DEVICE_TABLE(of). Leonard Crestez (4): cpufreq: Add imx-cpufreq-dt driver dt-bindings: imx-cpufreq-dt: Document opp-supported-hw usage arm64: dts: imx8mm: Add cpu speed grading and all OPPs arm64: dts: imx8mq: Add cpu speed grading and all OPPs .../bindings/cpufreq/imx-cpufreq-dt.txt | 37 +++++++ arch/arm64/boot/dts/freescale/imx8mm.dtsi | 17 +++- arch/arm64/boot/dts/freescale/imx8mq.dtsi | 26 ++++- drivers/cpufreq/Kconfig.arm | 10 ++ drivers/cpufreq/Makefile | 1 + drivers/cpufreq/cpufreq-dt-platdev.c | 3 + drivers/cpufreq/imx-cpufreq-dt.c | 96 +++++++++++++++++++ drivers/soc/imx/soc-imx8.c | 3 + 8 files changed, 191 insertions(+), 2 deletions(-) create mode 100644 Documentation/devicetree/bindings/cpufreq/imx-cpufreq-dt.txt create mode 100644 drivers/cpufreq/imx-cpufreq-dt.c -- 2.17.1
