mbox series

[v4,0/5] cpufreq: Add imx-cpufreq-dt driver for speed grading

Message ID cover.1557742902.git.leonard.crestez@nxp.com (mailing list archive)
Headers show
Series cpufreq: Add imx-cpufreq-dt driver for speed grading | expand

Message

Leonard Crestez May 13, 2019, 11:01 a.m. UTC
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 v3:
 * Drop default m entirely (Viresh)
Link to v3: https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=114685

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 devicetree 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/

Driver is built as a module. It depends on nvmem-imx which can also be a
module.

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.

Leonard Crestez (5):
  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
  arm64: defconfig: ARM_IMX_CPUFREQ_DT=m

 .../bindings/cpufreq/imx-cpufreq-dt.txt       | 37 +++++++
 arch/arm64/boot/dts/freescale/imx8mm.dtsi     | 17 +++-
 arch/arm64/boot/dts/freescale/imx8mq.dtsi     | 26 ++++-
 arch/arm64/configs/defconfig                  |  1 +
 drivers/cpufreq/Kconfig.arm                   |  9 ++
 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 +
 9 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

Comments

Viresh Kumar May 14, 2019, 7:13 a.m. UTC | #1
On 13-05-19, 11:01, 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.
> 
> Driver reads from nvmem and calls dev_pm_opp_set_supported_hw before
> registering cpufreq-dt.

Who will apply patches 3-5 ?
Shawn Guo May 20, 2019, 7:14 a.m. UTC | #2
On Tue, May 14, 2019 at 12:43:22PM +0530, Viresh Kumar wrote:
> On 13-05-19, 11:01, 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.
> > 
> > Driver reads from nvmem and calls dev_pm_opp_set_supported_hw before
> > registering cpufreq-dt.
> 
> Who will apply patches 3-5 ?

Me.  Will apply them after the first two get applied.

Shawn
Viresh Kumar May 20, 2019, 10:13 a.m. UTC | #3
On 20-05-19, 15:14, Shawn Guo wrote:
> On Tue, May 14, 2019 at 12:43:22PM +0530, Viresh Kumar wrote:
> > On 13-05-19, 11:01, 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.
> > > 
> > > Driver reads from nvmem and calls dev_pm_opp_set_supported_hw before
> > > registering cpufreq-dt.
> > 
> > Who will apply patches 3-5 ?
> 
> Me.  Will apply them after the first two get applied.

Applied just now.