mbox series

[V12,00/14] Krait clocks + Krait CPUfreq

Message ID 1534248753-2440-1-git-send-email-sricharan@codeaurora.org (mailing list archive)
Headers show
Series Krait clocks + Krait CPUfreq | expand

Message

Sricharan Ramabadhran Aug. 14, 2018, 12:12 p.m. UTC
[v12]
  * Added my signed-off that was missing in some patches.
  * Added Bjorn's acked that i missed earlier.

[v11]
  * Dropped patch 13 and 14 from v10 and
    merged the qcom-cpufreq-krait driver to the existing qcom-cpufreq-kryo.c
  * Rebased on top of clk-next
  * Fixed a bug while populating the pvs version for krait.

[v10]
  * Addressed Stephen's comments to add clocks bindings properties
    to the newly introduced nodes.
  * Added a change to include opp-supported-hw to qcom-cpufreq.c
  * Rebased on top of clk-next
  * Although there were minor changes to bindings and the driver
    retained the acked-by tags from Rob and Viresh respectively.    

[v9]
  * Fixed a rebase issue in Makefile and added Tag from Robh.

[v8]
  * Fixed a bug in path#14 pointed out by Viresh and also added tags.
    No change in any other patch.

[v7]
  * Fixed comments from Viresh for cleaning up the error handling
    in qcom-cpufreq.c. Also changed the init function to lateinit
    call. This is required because nvmem which gets initialised with
    module_init needs to go first.
  * Fixed Rob's comments for bindings documentation
  * Fixed kbuild build issue in clk-lpc32xx.c
  * Rebased on top of clk-next

[v6]
  * Adrressed comments from Viresh for patch #14 in v5 [5]
  * Introduced a new binding operating-points-v2-krait-cpu
    as per discussion with Rob
  * Added Review tags

[v5]
  * Addressed comments from Rob for bindings
  * Addressed comments from Viresh to use dev_pm_opp_set_prop_name, accordingly
    dropped patch #12 and corrected patch #11 from previous patch set in [4]
  * Converted to use #spdx tags for newly introduced files

Mostly a resend of the v3 posted by Stephen quite some time back [1]
except for few changes.
  Based on reading some feedback from list,
  * Dropped the patch "clk: Add safe switch hook" from v3 [2].
    Now this is taken care by patch#10 in this series only for Krait.
  * Dropped the path "clk: Avoid sending high rates to downstream
		      clocks during set_rate" from v3 [3].
  * Rebased on top of clk-next.
  * Dropped the DT update from the series. Will send separately
  * Now with cpufreq-dt+opp supporting voltage scaling, registering the
    krait cpu supplies in DT should be sufficient. But one issue is,
    the qcom-cpufreq drivers reads the efuse and based on that registers
    the opp data and then registers the cpufreq-dt device. So when
    cpufreq-dt driver probes and registers the regulator to the OPP framework,
    it expects that the opp data for the device should not be registered before
    the regulator. Will send a RFC patch removing that check, to find out the
    right way of doing it.

These patches provide cpufreq scaling on devices with Krait CPUs.
In Krait CPU designs there's one PLL and two muxes per CPU, allowing
us to switch CPU frequencies independently.

				 secondary
	 +-----+                    +
	 | QSB |-------+------------|\
	 +-----+       |            | |-+
		       |    +-------|/  |
		       |    |       +   |
	 +-----+       |    |           |
	 | PLL |----+-------+           |   primary
	 +-----+    |  |                |     +
		    |  |                +-----|\       +------+
	 +-------+  |  |                      | \      |      |
	 | HFPLL |----------+-----------------|  |-----| CPU0 |
	 +-------+  |  |    |                 |  |     |      |
		    |  |    | +-----+         | /      +------+
		    |  |    +-| / 2 |---------|/
		    |  |      +-----+         +
		    |  |         secondary
		    |  |            +
		    |  +------------|\
		    |               | |-+
		    +---------------|/  |   primary
				    +   |     +
					+-----|\       +------+
	 +-------+                            | \      |      |
	 | HFPLL |----------------------------|  |-----| CPU1 |
	 +-------+          |                 |  |     |      |
			    | +-----+         | /      +------+
			    +-| / 2 |---------|/
			      +-----+         +

To support this in the common clock framework we model the muxes,
dividers, and PLLs as different clocks. CPUfreq only interacts
with the primary mux (farthest right in the diagram). When CPUfreq
sets a rate, the mux code finds the best parent that can provide the rate.
Due to the design, QSB and the top PLL are always a fixed rate and thus
only support one frequency each. These sources provide the lowest
frequencies for the CPUs. The HFPLLs are where we can make the CPU go
faster (GHz range). Sometimes we need to run the HFPLL twice as
fast and divide it by two to get a particular frequency.

When switching rates we can't leave the CPU clocked by the HFPLL because
we need to turn off the output of the PLL when changing its frequency.
This means we have to switch over to the secondary mux and use one of the
fixed sources. This is why we need something like the safe parent patch.

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/332607.html
[2] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/332615.html
[3] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/332608.html
[4] https://lwn.net/Articles/740994/ 
[5] https://lkml.org/lkml/2017/12/19/537


Sricharan R (3):
  clk: qcom: Add safe switch hook for krait mux clocks
  cpufreq: qcom: Re-organise kryo cpufreq to use it for other nvmem
    based qcom socs
  cpufreq: qcom: Add support for krait based socs

Stephen Boyd (11):
  ARM: Add Krait L2 register accessor functions
  clk: qcom: Add support for High-Frequency PLLs (HFPLLs)
  clk: qcom: Add HFPLL driver
  dt-bindings: clock: Document qcom,hfpll
  clk: qcom: Add MSM8960/APQ8064's HFPLLs
  clk: qcom: Add IPQ806X's HFPLLs
  clk: qcom: Add support for Krait clocks
  clk: qcom: Add KPSS ACC/GCC driver
  dt-bindings: arm: Document qcom,kpss-gcc
  clk: qcom: Add Krait clock controller driver
  dt-bindings: clock: Document qcom,krait-cc

 .../devicetree/bindings/arm/msm/qcom,kpss-acc.txt  |  19 +
 .../devicetree/bindings/arm/msm/qcom,kpss-gcc.txt  |  44 +++
 .../devicetree/bindings/clock/qcom,hfpll.txt       |  60 ++++
 .../devicetree/bindings/clock/qcom,krait-cc.txt    |  34 ++
 .../{kryo-cpufreq.txt => qcom-nvmem-cpufreq.txt}   |   7 +-
 arch/arm/common/Kconfig                            |   3 +
 arch/arm/common/Makefile                           |   1 +
 arch/arm/common/krait-l2-accessors.c               |  48 +++
 arch/arm/include/asm/krait-l2-accessors.h          |   9 +
 drivers/clk/qcom/Kconfig                           |  28 ++
 drivers/clk/qcom/Makefile                          |   5 +
 drivers/clk/qcom/clk-hfpll.c                       | 244 +++++++++++++
 drivers/clk/qcom/clk-hfpll.h                       |  44 +++
 drivers/clk/qcom/clk-krait.c                       | 126 +++++++
 drivers/clk/qcom/clk-krait.h                       |  40 +++
 drivers/clk/qcom/gcc-ipq806x.c                     |  82 +++++
 drivers/clk/qcom/gcc-msm8960.c                     | 172 +++++++++
 drivers/clk/qcom/hfpll.c                           |  96 +++++
 drivers/clk/qcom/kpss-xcc.c                        |  87 +++++
 drivers/clk/qcom/krait-cc.c                        | 397 +++++++++++++++++++++
 drivers/cpufreq/Kconfig.arm                        |   6 +-
 drivers/cpufreq/Makefile                           |   2 +-
 drivers/cpufreq/cpufreq-dt-platdev.c               |   5 +
 drivers/cpufreq/qcom-cpufreq-kryo.c                | 232 ------------
 drivers/cpufreq/qcom-cpufreq-nvmem.c               | 387 ++++++++++++++++++++
 include/dt-bindings/clock/qcom,gcc-msm8960.h       |   2 +
 26 files changed, 1941 insertions(+), 239 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/msm/qcom,kpss-gcc.txt
 create mode 100644 Documentation/devicetree/bindings/clock/qcom,hfpll.txt
 create mode 100644 Documentation/devicetree/bindings/clock/qcom,krait-cc.txt
 rename Documentation/devicetree/bindings/opp/{kryo-cpufreq.txt => qcom-nvmem-cpufreq.txt} (98%)
 create mode 100644 arch/arm/common/krait-l2-accessors.c
 create mode 100644 arch/arm/include/asm/krait-l2-accessors.h
 create mode 100644 drivers/clk/qcom/clk-hfpll.c
 create mode 100644 drivers/clk/qcom/clk-hfpll.h
 create mode 100644 drivers/clk/qcom/clk-krait.c
 create mode 100644 drivers/clk/qcom/clk-krait.h
 create mode 100644 drivers/clk/qcom/hfpll.c
 create mode 100644 drivers/clk/qcom/kpss-xcc.c
 create mode 100644 drivers/clk/qcom/krait-cc.c
 delete mode 100644 drivers/cpufreq/qcom-cpufreq-kryo.c
 create mode 100644 drivers/cpufreq/qcom-cpufreq-nvmem.c

Comments

Sricharan Ramabadhran Aug. 14, 2018, 12:20 p.m. UTC | #1
Hi Craig,

On 8/14/2018 5:42 PM, Sricharan R wrote:
> [v12]
>   * Added my signed-off that was missing in some patches.
>   * Added Bjorn's acked that i missed earlier.
> 

  Can you give this a try on your 8974 device and check if the
  pvs version reporting, scaling for higher frequencies are fine ?
  Sorry, i could not get hold of a 8974 device. So in-case if you still
  have the issues with higher frequencies, can you give a quick debug
  and report. That would be of great help.

Regards,
 Sricharan


> [v11]
>   * Dropped patch 13 and 14 from v10 and
>     merged the qcom-cpufreq-krait driver to the existing qcom-cpufreq-kryo.c
>   * Rebased on top of clk-next
>   * Fixed a bug while populating the pvs version for krait.
> 
> [v10]
>   * Addressed Stephen's comments to add clocks bindings properties
>     to the newly introduced nodes.
>   * Added a change to include opp-supported-hw to qcom-cpufreq.c
>   * Rebased on top of clk-next
>   * Although there were minor changes to bindings and the driver
>     retained the acked-by tags from Rob and Viresh respectively.    
> 
> [v9]
>   * Fixed a rebase issue in Makefile and added Tag from Robh.
> 
> [v8]
>   * Fixed a bug in path#14 pointed out by Viresh and also added tags.
>     No change in any other patch.
> 
> [v7]
>   * Fixed comments from Viresh for cleaning up the error handling
>     in qcom-cpufreq.c. Also changed the init function to lateinit
>     call. This is required because nvmem which gets initialised with
>     module_init needs to go first.
>   * Fixed Rob's comments for bindings documentation
>   * Fixed kbuild build issue in clk-lpc32xx.c
>   * Rebased on top of clk-next
> 
> [v6]
>   * Adrressed comments from Viresh for patch #14 in v5 [5]
>   * Introduced a new binding operating-points-v2-krait-cpu
>     as per discussion with Rob
>   * Added Review tags
> 
> [v5]
>   * Addressed comments from Rob for bindings
>   * Addressed comments from Viresh to use dev_pm_opp_set_prop_name, accordingly
>     dropped patch #12 and corrected patch #11 from previous patch set in [4]
>   * Converted to use #spdx tags for newly introduced files
> 
> Mostly a resend of the v3 posted by Stephen quite some time back [1]
> except for few changes.
>   Based on reading some feedback from list,
>   * Dropped the patch "clk: Add safe switch hook" from v3 [2].
>     Now this is taken care by patch#10 in this series only for Krait.
>   * Dropped the path "clk: Avoid sending high rates to downstream
> 		      clocks during set_rate" from v3 [3].
>   * Rebased on top of clk-next.
>   * Dropped the DT update from the series. Will send separately
>   * Now with cpufreq-dt+opp supporting voltage scaling, registering the
>     krait cpu supplies in DT should be sufficient. But one issue is,
>     the qcom-cpufreq drivers reads the efuse and based on that registers
>     the opp data and then registers the cpufreq-dt device. So when
>     cpufreq-dt driver probes and registers the regulator to the OPP framework,
>     it expects that the opp data for the device should not be registered before
>     the regulator. Will send a RFC patch removing that check, to find out the
>     right way of doing it.
> 
> These patches provide cpufreq scaling on devices with Krait CPUs.
> In Krait CPU designs there's one PLL and two muxes per CPU, allowing
> us to switch CPU frequencies independently.
> 
> 				 secondary
> 	 +-----+                    +
> 	 | QSB |-------+------------|\
> 	 +-----+       |            | |-+
> 		       |    +-------|/  |
> 		       |    |       +   |
> 	 +-----+       |    |           |
> 	 | PLL |----+-------+           |   primary
> 	 +-----+    |  |                |     +
> 		    |  |                +-----|\       +------+
> 	 +-------+  |  |                      | \      |      |
> 	 | HFPLL |----------+-----------------|  |-----| CPU0 |
> 	 +-------+  |  |    |                 |  |     |      |
> 		    |  |    | +-----+         | /      +------+
> 		    |  |    +-| / 2 |---------|/
> 		    |  |      +-----+         +
> 		    |  |         secondary
> 		    |  |            +
> 		    |  +------------|\
> 		    |               | |-+
> 		    +---------------|/  |   primary
> 				    +   |     +
> 					+-----|\       +------+
> 	 +-------+                            | \      |      |
> 	 | HFPLL |----------------------------|  |-----| CPU1 |
> 	 +-------+          |                 |  |     |      |
> 			    | +-----+         | /      +------+
> 			    +-| / 2 |---------|/
> 			      +-----+         +
> 
> To support this in the common clock framework we model the muxes,
> dividers, and PLLs as different clocks. CPUfreq only interacts
> with the primary mux (farthest right in the diagram). When CPUfreq
> sets a rate, the mux code finds the best parent that can provide the rate.
> Due to the design, QSB and the top PLL are always a fixed rate and thus
> only support one frequency each. These sources provide the lowest
> frequencies for the CPUs. The HFPLLs are where we can make the CPU go
> faster (GHz range). Sometimes we need to run the HFPLL twice as
> fast and divide it by two to get a particular frequency.
> 
> When switching rates we can't leave the CPU clocked by the HFPLL because
> we need to turn off the output of the PLL when changing its frequency.
> This means we have to switch over to the secondary mux and use one of the
> fixed sources. This is why we need something like the safe parent patch.
> 
> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/332607.html
> [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/332615.html
> [3] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/332608.html
> [4] https://lwn.net/Articles/740994/ 
> [5] https://lkml.org/lkml/2017/12/19/537
> 
> 
> Sricharan R (3):
>   clk: qcom: Add safe switch hook for krait mux clocks
>   cpufreq: qcom: Re-organise kryo cpufreq to use it for other nvmem
>     based qcom socs
>   cpufreq: qcom: Add support for krait based socs
> 
> Stephen Boyd (11):
>   ARM: Add Krait L2 register accessor functions
>   clk: qcom: Add support for High-Frequency PLLs (HFPLLs)
>   clk: qcom: Add HFPLL driver
>   dt-bindings: clock: Document qcom,hfpll
>   clk: qcom: Add MSM8960/APQ8064's HFPLLs
>   clk: qcom: Add IPQ806X's HFPLLs
>   clk: qcom: Add support for Krait clocks
>   clk: qcom: Add KPSS ACC/GCC driver
>   dt-bindings: arm: Document qcom,kpss-gcc
>   clk: qcom: Add Krait clock controller driver
>   dt-bindings: clock: Document qcom,krait-cc
> 
>  .../devicetree/bindings/arm/msm/qcom,kpss-acc.txt  |  19 +
>  .../devicetree/bindings/arm/msm/qcom,kpss-gcc.txt  |  44 +++
>  .../devicetree/bindings/clock/qcom,hfpll.txt       |  60 ++++
>  .../devicetree/bindings/clock/qcom,krait-cc.txt    |  34 ++
>  .../{kryo-cpufreq.txt => qcom-nvmem-cpufreq.txt}   |   7 +-
>  arch/arm/common/Kconfig                            |   3 +
>  arch/arm/common/Makefile                           |   1 +
>  arch/arm/common/krait-l2-accessors.c               |  48 +++
>  arch/arm/include/asm/krait-l2-accessors.h          |   9 +
>  drivers/clk/qcom/Kconfig                           |  28 ++
>  drivers/clk/qcom/Makefile                          |   5 +
>  drivers/clk/qcom/clk-hfpll.c                       | 244 +++++++++++++
>  drivers/clk/qcom/clk-hfpll.h                       |  44 +++
>  drivers/clk/qcom/clk-krait.c                       | 126 +++++++
>  drivers/clk/qcom/clk-krait.h                       |  40 +++
>  drivers/clk/qcom/gcc-ipq806x.c                     |  82 +++++
>  drivers/clk/qcom/gcc-msm8960.c                     | 172 +++++++++
>  drivers/clk/qcom/hfpll.c                           |  96 +++++
>  drivers/clk/qcom/kpss-xcc.c                        |  87 +++++
>  drivers/clk/qcom/krait-cc.c                        | 397 +++++++++++++++++++++
>  drivers/cpufreq/Kconfig.arm                        |   6 +-
>  drivers/cpufreq/Makefile                           |   2 +-
>  drivers/cpufreq/cpufreq-dt-platdev.c               |   5 +
>  drivers/cpufreq/qcom-cpufreq-kryo.c                | 232 ------------
>  drivers/cpufreq/qcom-cpufreq-nvmem.c               | 387 ++++++++++++++++++++
>  include/dt-bindings/clock/qcom,gcc-msm8960.h       |   2 +
>  26 files changed, 1941 insertions(+), 239 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/arm/msm/qcom,kpss-gcc.txt
>  create mode 100644 Documentation/devicetree/bindings/clock/qcom,hfpll.txt
>  create mode 100644 Documentation/devicetree/bindings/clock/qcom,krait-cc.txt
>  rename Documentation/devicetree/bindings/opp/{kryo-cpufreq.txt => qcom-nvmem-cpufreq.txt} (98%)
>  create mode 100644 arch/arm/common/krait-l2-accessors.c
>  create mode 100644 arch/arm/include/asm/krait-l2-accessors.h
>  create mode 100644 drivers/clk/qcom/clk-hfpll.c
>  create mode 100644 drivers/clk/qcom/clk-hfpll.h
>  create mode 100644 drivers/clk/qcom/clk-krait.c
>  create mode 100644 drivers/clk/qcom/clk-krait.h
>  create mode 100644 drivers/clk/qcom/hfpll.c
>  create mode 100644 drivers/clk/qcom/kpss-xcc.c
>  create mode 100644 drivers/clk/qcom/krait-cc.c
>  delete mode 100644 drivers/cpufreq/qcom-cpufreq-kryo.c
>  create mode 100644 drivers/cpufreq/qcom-cpufreq-nvmem.c
>
Sricharan Ramabadhran Sept. 7, 2018, 9:57 a.m. UTC | #2
Hi Craig,


>> [v12]
>>   * Added my signed-off that was missing in some patches.
>>   * Added Bjorn's acked that i missed earlier.
>>
> 
>   Can you give this a try on your 8974 device and check if the
>   pvs version reporting, scaling for higher frequencies are fine ?
>   Sorry, i could not get hold of a 8974 device. So in-case if you still
>   have the issues with higher frequencies, can you give a quick debug
>   and report. That would be of great help.
> 
   Ping on this ..

Regards,
 Sricharan

> Regards,
>  Sricharan
> 
> 
>> [v11]
>>   * Dropped patch 13 and 14 from v10 and
>>     merged the qcom-cpufreq-krait driver to the existing qcom-cpufreq-kryo.c
>>   * Rebased on top of clk-next
>>   * Fixed a bug while populating the pvs version for krait.
>>
>> [v10]
>>   * Addressed Stephen's comments to add clocks bindings properties
>>     to the newly introduced nodes.
>>   * Added a change to include opp-supported-hw to qcom-cpufreq.c
>>   * Rebased on top of clk-next
>>   * Although there were minor changes to bindings and the driver
>>     retained the acked-by tags from Rob and Viresh respectively.    
>>
>> [v9]
>>   * Fixed a rebase issue in Makefile and added Tag from Robh.
>>
>> [v8]
>>   * Fixed a bug in path#14 pointed out by Viresh and also added tags.
>>     No change in any other patch.
>>
>> [v7]
>>   * Fixed comments from Viresh for cleaning up the error handling
>>     in qcom-cpufreq.c. Also changed the init function to lateinit
>>     call. This is required because nvmem which gets initialised with
>>     module_init needs to go first.
>>   * Fixed Rob's comments for bindings documentation
>>   * Fixed kbuild build issue in clk-lpc32xx.c
>>   * Rebased on top of clk-next
>>
>> [v6]
>>   * Adrressed comments from Viresh for patch #14 in v5 [5]
>>   * Introduced a new binding operating-points-v2-krait-cpu
>>     as per discussion with Rob
>>   * Added Review tags
>>
>> [v5]
>>   * Addressed comments from Rob for bindings
>>   * Addressed comments from Viresh to use dev_pm_opp_set_prop_name, accordingly
>>     dropped patch #12 and corrected patch #11 from previous patch set in [4]
>>   * Converted to use #spdx tags for newly introduced files
>>
>> Mostly a resend of the v3 posted by Stephen quite some time back [1]
>> except for few changes.
>>   Based on reading some feedback from list,
>>   * Dropped the patch "clk: Add safe switch hook" from v3 [2].
>>     Now this is taken care by patch#10 in this series only for Krait.
>>   * Dropped the path "clk: Avoid sending high rates to downstream
>> 		      clocks during set_rate" from v3 [3].
>>   * Rebased on top of clk-next.
>>   * Dropped the DT update from the series. Will send separately
>>   * Now with cpufreq-dt+opp supporting voltage scaling, registering the
>>     krait cpu supplies in DT should be sufficient. But one issue is,
>>     the qcom-cpufreq drivers reads the efuse and based on that registers
>>     the opp data and then registers the cpufreq-dt device. So when
>>     cpufreq-dt driver probes and registers the regulator to the OPP framework,
>>     it expects that the opp data for the device should not be registered before
>>     the regulator. Will send a RFC patch removing that check, to find out the
>>     right way of doing it.
>>
>> These patches provide cpufreq scaling on devices with Krait CPUs.
>> In Krait CPU designs there's one PLL and two muxes per CPU, allowing
>> us to switch CPU frequencies independently.
>>
>> 				 secondary
>> 	 +-----+                    +
>> 	 | QSB |-------+------------|\
>> 	 +-----+       |            | |-+
>> 		       |    +-------|/  |
>> 		       |    |       +   |
>> 	 +-----+       |    |           |
>> 	 | PLL |----+-------+           |   primary
>> 	 +-----+    |  |                |     +
>> 		    |  |                +-----|\       +------+
>> 	 +-------+  |  |                      | \      |      |
>> 	 | HFPLL |----------+-----------------|  |-----| CPU0 |
>> 	 +-------+  |  |    |                 |  |     |      |
>> 		    |  |    | +-----+         | /      +------+
>> 		    |  |    +-| / 2 |---------|/
>> 		    |  |      +-----+         +
>> 		    |  |         secondary
>> 		    |  |            +
>> 		    |  +------------|\
>> 		    |               | |-+
>> 		    +---------------|/  |   primary
>> 				    +   |     +
>> 					+-----|\       +------+
>> 	 +-------+                            | \      |      |
>> 	 | HFPLL |----------------------------|  |-----| CPU1 |
>> 	 +-------+          |                 |  |     |      |
>> 			    | +-----+         | /      +------+
>> 			    +-| / 2 |---------|/
>> 			      +-----+         +
>>
>> To support this in the common clock framework we model the muxes,
>> dividers, and PLLs as different clocks. CPUfreq only interacts
>> with the primary mux (farthest right in the diagram). When CPUfreq
>> sets a rate, the mux code finds the best parent that can provide the rate.
>> Due to the design, QSB and the top PLL are always a fixed rate and thus
>> only support one frequency each. These sources provide the lowest
>> frequencies for the CPUs. The HFPLLs are where we can make the CPU go
>> faster (GHz range). Sometimes we need to run the HFPLL twice as
>> fast and divide it by two to get a particular frequency.
>>
>> When switching rates we can't leave the CPU clocked by the HFPLL because
>> we need to turn off the output of the PLL when changing its frequency.
>> This means we have to switch over to the secondary mux and use one of the
>> fixed sources. This is why we need something like the safe parent patch.
>>
>> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/332607.html
>> [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/332615.html
>> [3] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/332608.html
>> [4] https://lwn.net/Articles/740994/ 
>> [5] https://lkml.org/lkml/2017/12/19/537
>>
>>
>> Sricharan R (3):
>>   clk: qcom: Add safe switch hook for krait mux clocks
>>   cpufreq: qcom: Re-organise kryo cpufreq to use it for other nvmem
>>     based qcom socs
>>   cpufreq: qcom: Add support for krait based socs
>>
>> Stephen Boyd (11):
>>   ARM: Add Krait L2 register accessor functions
>>   clk: qcom: Add support for High-Frequency PLLs (HFPLLs)
>>   clk: qcom: Add HFPLL driver
>>   dt-bindings: clock: Document qcom,hfpll
>>   clk: qcom: Add MSM8960/APQ8064's HFPLLs
>>   clk: qcom: Add IPQ806X's HFPLLs
>>   clk: qcom: Add support for Krait clocks
>>   clk: qcom: Add KPSS ACC/GCC driver
>>   dt-bindings: arm: Document qcom,kpss-gcc
>>   clk: qcom: Add Krait clock controller driver
>>   dt-bindings: clock: Document qcom,krait-cc
>>
>>  .../devicetree/bindings/arm/msm/qcom,kpss-acc.txt  |  19 +
>>  .../devicetree/bindings/arm/msm/qcom,kpss-gcc.txt  |  44 +++
>>  .../devicetree/bindings/clock/qcom,hfpll.txt       |  60 ++++
>>  .../devicetree/bindings/clock/qcom,krait-cc.txt    |  34 ++
>>  .../{kryo-cpufreq.txt => qcom-nvmem-cpufreq.txt}   |   7 +-
>>  arch/arm/common/Kconfig                            |   3 +
>>  arch/arm/common/Makefile                           |   1 +
>>  arch/arm/common/krait-l2-accessors.c               |  48 +++
>>  arch/arm/include/asm/krait-l2-accessors.h          |   9 +
>>  drivers/clk/qcom/Kconfig                           |  28 ++
>>  drivers/clk/qcom/Makefile                          |   5 +
>>  drivers/clk/qcom/clk-hfpll.c                       | 244 +++++++++++++
>>  drivers/clk/qcom/clk-hfpll.h                       |  44 +++
>>  drivers/clk/qcom/clk-krait.c                       | 126 +++++++
>>  drivers/clk/qcom/clk-krait.h                       |  40 +++
>>  drivers/clk/qcom/gcc-ipq806x.c                     |  82 +++++
>>  drivers/clk/qcom/gcc-msm8960.c                     | 172 +++++++++
>>  drivers/clk/qcom/hfpll.c                           |  96 +++++
>>  drivers/clk/qcom/kpss-xcc.c                        |  87 +++++
>>  drivers/clk/qcom/krait-cc.c                        | 397 +++++++++++++++++++++
>>  drivers/cpufreq/Kconfig.arm                        |   6 +-
>>  drivers/cpufreq/Makefile                           |   2 +-
>>  drivers/cpufreq/cpufreq-dt-platdev.c               |   5 +
>>  drivers/cpufreq/qcom-cpufreq-kryo.c                | 232 ------------
>>  drivers/cpufreq/qcom-cpufreq-nvmem.c               | 387 ++++++++++++++++++++
>>  include/dt-bindings/clock/qcom,gcc-msm8960.h       |   2 +
>>  26 files changed, 1941 insertions(+), 239 deletions(-)
>>  create mode 100644 Documentation/devicetree/bindings/arm/msm/qcom,kpss-gcc.txt
>>  create mode 100644 Documentation/devicetree/bindings/clock/qcom,hfpll.txt
>>  create mode 100644 Documentation/devicetree/bindings/clock/qcom,krait-cc.txt
>>  rename Documentation/devicetree/bindings/opp/{kryo-cpufreq.txt => qcom-nvmem-cpufreq.txt} (98%)
>>  create mode 100644 arch/arm/common/krait-l2-accessors.c
>>  create mode 100644 arch/arm/include/asm/krait-l2-accessors.h
>>  create mode 100644 drivers/clk/qcom/clk-hfpll.c
>>  create mode 100644 drivers/clk/qcom/clk-hfpll.h
>>  create mode 100644 drivers/clk/qcom/clk-krait.c
>>  create mode 100644 drivers/clk/qcom/clk-krait.h
>>  create mode 100644 drivers/clk/qcom/hfpll.c
>>  create mode 100644 drivers/clk/qcom/kpss-xcc.c
>>  create mode 100644 drivers/clk/qcom/krait-cc.c
>>  delete mode 100644 drivers/cpufreq/qcom-cpufreq-kryo.c
>>  create mode 100644 drivers/cpufreq/qcom-cpufreq-nvmem.c
>>
>
Craig Tatlor Sept. 7, 2018, 2:28 p.m. UTC | #3
On 7 September 2018 10:57:34 BST, Sricharan R <sricharan@codeaurora.org> wrote:
>Hi Craig,
>
>
>>> [v12]
>>>   * Added my signed-off that was missing in some patches.
>>>   * Added Bjorn's acked that i missed earlier.
>>>
>> 
>>   Can you give this a try on your 8974 device and check if the
>>   pvs version reporting, scaling for higher frequencies are fine ?
>>   Sorry, i could not get hold of a 8974 device. So in-case if you
>still
>>   have the issues with higher frequencies, can you give a quick debug
>>   and report. That would be of great help.
>> 
>   Ping on this ..

Hi, didn't see your last message,

Will have a try on mine in the weekend and report back.
>
>Regards,
> Sricharan
>
>> Regards,
>>  Sricharan
>> 
>> 
>>> [v11]
>>>   * Dropped patch 13 and 14 from v10 and
>>>     merged the qcom-cpufreq-krait driver to the existing
>qcom-cpufreq-kryo.c
>>>   * Rebased on top of clk-next
>>>   * Fixed a bug while populating the pvs version for krait.
>>>
>>> [v10]
>>>   * Addressed Stephen's comments to add clocks bindings properties
>>>     to the newly introduced nodes.
>>>   * Added a change to include opp-supported-hw to qcom-cpufreq.c
>>>   * Rebased on top of clk-next
>>>   * Although there were minor changes to bindings and the driver
>>>     retained the acked-by tags from Rob and Viresh respectively.    
>>>
>>> [v9]
>>>   * Fixed a rebase issue in Makefile and added Tag from Robh.
>>>
>>> [v8]
>>>   * Fixed a bug in path#14 pointed out by Viresh and also added
>tags.
>>>     No change in any other patch.
>>>
>>> [v7]
>>>   * Fixed comments from Viresh for cleaning up the error handling
>>>     in qcom-cpufreq.c. Also changed the init function to lateinit
>>>     call. This is required because nvmem which gets initialised with
>>>     module_init needs to go first.
>>>   * Fixed Rob's comments for bindings documentation
>>>   * Fixed kbuild build issue in clk-lpc32xx.c
>>>   * Rebased on top of clk-next
>>>
>>> [v6]
>>>   * Adrressed comments from Viresh for patch #14 in v5 [5]
>>>   * Introduced a new binding operating-points-v2-krait-cpu
>>>     as per discussion with Rob
>>>   * Added Review tags
>>>
>>> [v5]
>>>   * Addressed comments from Rob for bindings
>>>   * Addressed comments from Viresh to use dev_pm_opp_set_prop_name,
>accordingly
>>>     dropped patch #12 and corrected patch #11 from previous patch
>set in [4]
>>>   * Converted to use #spdx tags for newly introduced files
>>>
>>> Mostly a resend of the v3 posted by Stephen quite some time back [1]
>>> except for few changes.
>>>   Based on reading some feedback from list,
>>>   * Dropped the patch "clk: Add safe switch hook" from v3 [2].
>>>     Now this is taken care by patch#10 in this series only for
>Krait.
>>>   * Dropped the path "clk: Avoid sending high rates to downstream
>>> 		      clocks during set_rate" from v3 [3].
>>>   * Rebased on top of clk-next.
>>>   * Dropped the DT update from the series. Will send separately
>>>   * Now with cpufreq-dt+opp supporting voltage scaling, registering
>the
>>>     krait cpu supplies in DT should be sufficient. But one issue is,
>>>     the qcom-cpufreq drivers reads the efuse and based on that
>registers
>>>     the opp data and then registers the cpufreq-dt device. So when
>>>     cpufreq-dt driver probes and registers the regulator to the OPP
>framework,
>>>     it expects that the opp data for the device should not be
>registered before
>>>     the regulator. Will send a RFC patch removing that check, to
>find out the
>>>     right way of doing it.
>>>
>>> These patches provide cpufreq scaling on devices with Krait CPUs.
>>> In Krait CPU designs there's one PLL and two muxes per CPU, allowing
>>> us to switch CPU frequencies independently.
>>>
>>> 				 secondary
>>> 	 +-----+                    +
>>> 	 | QSB |-------+------------|\
>>> 	 +-----+       |            | |-+
>>> 		       |    +-------|/  |
>>> 		       |    |       +   |
>>> 	 +-----+       |    |           |
>>> 	 | PLL |----+-------+           |   primary
>>> 	 +-----+    |  |                |     +
>>> 		    |  |                +-----|\       +------+
>>> 	 +-------+  |  |                      | \      |      |
>>> 	 | HFPLL |----------+-----------------|  |-----| CPU0 |
>>> 	 +-------+  |  |    |                 |  |     |      |
>>> 		    |  |    | +-----+         | /      +------+
>>> 		    |  |    +-| / 2 |---------|/
>>> 		    |  |      +-----+         +
>>> 		    |  |         secondary
>>> 		    |  |            +
>>> 		    |  +------------|\
>>> 		    |               | |-+
>>> 		    +---------------|/  |   primary
>>> 				    +   |     +
>>> 					+-----|\       +------+
>>> 	 +-------+                            | \      |      |
>>> 	 | HFPLL |----------------------------|  |-----| CPU1 |
>>> 	 +-------+          |                 |  |     |      |
>>> 			    | +-----+         | /      +------+
>>> 			    +-| / 2 |---------|/
>>> 			      +-----+         +
>>>
>>> To support this in the common clock framework we model the muxes,
>>> dividers, and PLLs as different clocks. CPUfreq only interacts
>>> with the primary mux (farthest right in the diagram). When CPUfreq
>>> sets a rate, the mux code finds the best parent that can provide the
>rate.
>>> Due to the design, QSB and the top PLL are always a fixed rate and
>thus
>>> only support one frequency each. These sources provide the lowest
>>> frequencies for the CPUs. The HFPLLs are where we can make the CPU
>go
>>> faster (GHz range). Sometimes we need to run the HFPLL twice as
>>> fast and divide it by two to get a particular frequency.
>>>
>>> When switching rates we can't leave the CPU clocked by the HFPLL
>because
>>> we need to turn off the output of the PLL when changing its
>frequency.
>>> This means we have to switch over to the secondary mux and use one
>of the
>>> fixed sources. This is why we need something like the safe parent
>patch.
>>>
>>> [1]
>http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/332607.html
>>> [2]
>http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/332615.html
>>> [3]
>http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/332608.html
>>> [4] https://lwn.net/Articles/740994/ 
>>> [5] https://lkml.org/lkml/2017/12/19/537
>>>
>>>
>>> Sricharan R (3):
>>>   clk: qcom: Add safe switch hook for krait mux clocks
>>>   cpufreq: qcom: Re-organise kryo cpufreq to use it for other nvmem
>>>     based qcom socs
>>>   cpufreq: qcom: Add support for krait based socs
>>>
>>> Stephen Boyd (11):
>>>   ARM: Add Krait L2 register accessor functions
>>>   clk: qcom: Add support for High-Frequency PLLs (HFPLLs)
>>>   clk: qcom: Add HFPLL driver
>>>   dt-bindings: clock: Document qcom,hfpll
>>>   clk: qcom: Add MSM8960/APQ8064's HFPLLs
>>>   clk: qcom: Add IPQ806X's HFPLLs
>>>   clk: qcom: Add support for Krait clocks
>>>   clk: qcom: Add KPSS ACC/GCC driver
>>>   dt-bindings: arm: Document qcom,kpss-gcc
>>>   clk: qcom: Add Krait clock controller driver
>>>   dt-bindings: clock: Document qcom,krait-cc
>>>
>>>  .../devicetree/bindings/arm/msm/qcom,kpss-acc.txt  |  19 +
>>>  .../devicetree/bindings/arm/msm/qcom,kpss-gcc.txt  |  44 +++
>>>  .../devicetree/bindings/clock/qcom,hfpll.txt       |  60 ++++
>>>  .../devicetree/bindings/clock/qcom,krait-cc.txt    |  34 ++
>>>  .../{kryo-cpufreq.txt => qcom-nvmem-cpufreq.txt}   |   7 +-
>>>  arch/arm/common/Kconfig                            |   3 +
>>>  arch/arm/common/Makefile                           |   1 +
>>>  arch/arm/common/krait-l2-accessors.c               |  48 +++
>>>  arch/arm/include/asm/krait-l2-accessors.h          |   9 +
>>>  drivers/clk/qcom/Kconfig                           |  28 ++
>>>  drivers/clk/qcom/Makefile                          |   5 +
>>>  drivers/clk/qcom/clk-hfpll.c                       | 244
>+++++++++++++
>>>  drivers/clk/qcom/clk-hfpll.h                       |  44 +++
>>>  drivers/clk/qcom/clk-krait.c                       | 126 +++++++
>>>  drivers/clk/qcom/clk-krait.h                       |  40 +++
>>>  drivers/clk/qcom/gcc-ipq806x.c                     |  82 +++++
>>>  drivers/clk/qcom/gcc-msm8960.c                     | 172 +++++++++
>>>  drivers/clk/qcom/hfpll.c                           |  96 +++++
>>>  drivers/clk/qcom/kpss-xcc.c                        |  87 +++++
>>>  drivers/clk/qcom/krait-cc.c                        | 397
>+++++++++++++++++++++
>>>  drivers/cpufreq/Kconfig.arm                        |   6 +-
>>>  drivers/cpufreq/Makefile                           |   2 +-
>>>  drivers/cpufreq/cpufreq-dt-platdev.c               |   5 +
>>>  drivers/cpufreq/qcom-cpufreq-kryo.c                | 232
>------------
>>>  drivers/cpufreq/qcom-cpufreq-nvmem.c               | 387
>++++++++++++++++++++
>>>  include/dt-bindings/clock/qcom,gcc-msm8960.h       |   2 +
>>>  26 files changed, 1941 insertions(+), 239 deletions(-)
>>>  create mode 100644
>Documentation/devicetree/bindings/arm/msm/qcom,kpss-gcc.txt
>>>  create mode 100644
>Documentation/devicetree/bindings/clock/qcom,hfpll.txt
>>>  create mode 100644
>Documentation/devicetree/bindings/clock/qcom,krait-cc.txt
>>>  rename Documentation/devicetree/bindings/opp/{kryo-cpufreq.txt =>
>qcom-nvmem-cpufreq.txt} (98%)
>>>  create mode 100644 arch/arm/common/krait-l2-accessors.c
>>>  create mode 100644 arch/arm/include/asm/krait-l2-accessors.h
>>>  create mode 100644 drivers/clk/qcom/clk-hfpll.c
>>>  create mode 100644 drivers/clk/qcom/clk-hfpll.h
>>>  create mode 100644 drivers/clk/qcom/clk-krait.c
>>>  create mode 100644 drivers/clk/qcom/clk-krait.h
>>>  create mode 100644 drivers/clk/qcom/hfpll.c
>>>  create mode 100644 drivers/clk/qcom/kpss-xcc.c
>>>  create mode 100644 drivers/clk/qcom/krait-cc.c
>>>  delete mode 100644 drivers/cpufreq/qcom-cpufreq-kryo.c
>>>  create mode 100644 drivers/cpufreq/qcom-cpufreq-nvmem.c
>>>
>>
Craig Tatlor Sept. 19, 2018, 8:24 p.m. UTC | #4
Yup, this patch seems to have fixed the higher frequencies from the quick test I did.

On 7 September 2018 15:28:53 BST, Craig Tatlor <ctatlor97@gmail.com> wrote:
>
>
>On 7 September 2018 10:57:34 BST, Sricharan R
><sricharan@codeaurora.org> wrote:
>>Hi Craig,
>>
>>
>>>> [v12]
>>>>   * Added my signed-off that was missing in some patches.
>>>>   * Added Bjorn's acked that i missed earlier.
>>>>
>>> 
>>>   Can you give this a try on your 8974 device and check if the
>>>   pvs version reporting, scaling for higher frequencies are fine ?
>>>   Sorry, i could not get hold of a 8974 device. So in-case if you
>>still
>>>   have the issues with higher frequencies, can you give a quick
>debug
>>>   and report. That would be of great help.
>>> 
>>   Ping on this ..
>
>Hi, didn't see your last message,
>
>Will have a try on mine in the weekend and report back.
>>
>>Regards,
>> Sricharan
>>
>>> Regards,
>>>  Sricharan
>>> 
>>> 
>>>> [v11]
>>>>   * Dropped patch 13 and 14 from v10 and
>>>>     merged the qcom-cpufreq-krait driver to the existing
>>qcom-cpufreq-kryo.c
>>>>   * Rebased on top of clk-next
>>>>   * Fixed a bug while populating the pvs version for krait.
>>>>
>>>> [v10]
>>>>   * Addressed Stephen's comments to add clocks bindings properties
>>>>     to the newly introduced nodes.
>>>>   * Added a change to include opp-supported-hw to qcom-cpufreq.c
>>>>   * Rebased on top of clk-next
>>>>   * Although there were minor changes to bindings and the driver
>>>>     retained the acked-by tags from Rob and Viresh respectively.   
>
>>>>
>>>> [v9]
>>>>   * Fixed a rebase issue in Makefile and added Tag from Robh.
>>>>
>>>> [v8]
>>>>   * Fixed a bug in path#14 pointed out by Viresh and also added
>>tags.
>>>>     No change in any other patch.
>>>>
>>>> [v7]
>>>>   * Fixed comments from Viresh for cleaning up the error handling
>>>>     in qcom-cpufreq.c. Also changed the init function to lateinit
>>>>     call. This is required because nvmem which gets initialised
>with
>>>>     module_init needs to go first.
>>>>   * Fixed Rob's comments for bindings documentation
>>>>   * Fixed kbuild build issue in clk-lpc32xx.c
>>>>   * Rebased on top of clk-next
>>>>
>>>> [v6]
>>>>   * Adrressed comments from Viresh for patch #14 in v5 [5]
>>>>   * Introduced a new binding operating-points-v2-krait-cpu
>>>>     as per discussion with Rob
>>>>   * Added Review tags
>>>>
>>>> [v5]
>>>>   * Addressed comments from Rob for bindings
>>>>   * Addressed comments from Viresh to use dev_pm_opp_set_prop_name,
>>accordingly
>>>>     dropped patch #12 and corrected patch #11 from previous patch
>>set in [4]
>>>>   * Converted to use #spdx tags for newly introduced files
>>>>
>>>> Mostly a resend of the v3 posted by Stephen quite some time back
>[1]
>>>> except for few changes.
>>>>   Based on reading some feedback from list,
>>>>   * Dropped the patch "clk: Add safe switch hook" from v3 [2].
>>>>     Now this is taken care by patch#10 in this series only for
>>Krait.
>>>>   * Dropped the path "clk: Avoid sending high rates to downstream
>>>> 		      clocks during set_rate" from v3 [3].
>>>>   * Rebased on top of clk-next.
>>>>   * Dropped the DT update from the series. Will send separately
>>>>   * Now with cpufreq-dt+opp supporting voltage scaling, registering
>>the
>>>>     krait cpu supplies in DT should be sufficient. But one issue
>is,
>>>>     the qcom-cpufreq drivers reads the efuse and based on that
>>registers
>>>>     the opp data and then registers the cpufreq-dt device. So when
>>>>     cpufreq-dt driver probes and registers the regulator to the OPP
>>framework,
>>>>     it expects that the opp data for the device should not be
>>registered before
>>>>     the regulator. Will send a RFC patch removing that check, to
>>find out the
>>>>     right way of doing it.
>>>>
>>>> These patches provide cpufreq scaling on devices with Krait CPUs.
>>>> In Krait CPU designs there's one PLL and two muxes per CPU,
>allowing
>>>> us to switch CPU frequencies independently.
>>>>
>>>> 				 secondary
>>>> 	 +-----+                    +
>>>> 	 | QSB |-------+------------|\
>>>> 	 +-----+       |            | |-+
>>>> 		       |    +-------|/  |
>>>> 		       |    |       +   |
>>>> 	 +-----+       |    |           |
>>>> 	 | PLL |----+-------+           |   primary
>>>> 	 +-----+    |  |                |     +
>>>> 		    |  |                +-----|\       +------+
>>>> 	 +-------+  |  |                      | \      |      |
>>>> 	 | HFPLL |----------+-----------------|  |-----| CPU0 |
>>>> 	 +-------+  |  |    |                 |  |     |      |
>>>> 		    |  |    | +-----+         | /      +------+
>>>> 		    |  |    +-| / 2 |---------|/
>>>> 		    |  |      +-----+         +
>>>> 		    |  |         secondary
>>>> 		    |  |            +
>>>> 		    |  +------------|\
>>>> 		    |               | |-+
>>>> 		    +---------------|/  |   primary
>>>> 				    +   |     +
>>>> 					+-----|\       +------+
>>>> 	 +-------+                            | \      |      |
>>>> 	 | HFPLL |----------------------------|  |-----| CPU1 |
>>>> 	 +-------+          |                 |  |     |      |
>>>> 			    | +-----+         | /      +------+
>>>> 			    +-| / 2 |---------|/
>>>> 			      +-----+         +
>>>>
>>>> To support this in the common clock framework we model the muxes,
>>>> dividers, and PLLs as different clocks. CPUfreq only interacts
>>>> with the primary mux (farthest right in the diagram). When CPUfreq
>>>> sets a rate, the mux code finds the best parent that can provide
>the
>>rate.
>>>> Due to the design, QSB and the top PLL are always a fixed rate and
>>thus
>>>> only support one frequency each. These sources provide the lowest
>>>> frequencies for the CPUs. The HFPLLs are where we can make the CPU
>>go
>>>> faster (GHz range). Sometimes we need to run the HFPLL twice as
>>>> fast and divide it by two to get a particular frequency.
>>>>
>>>> When switching rates we can't leave the CPU clocked by the HFPLL
>>because
>>>> we need to turn off the output of the PLL when changing its
>>frequency.
>>>> This means we have to switch over to the secondary mux and use one
>>of the
>>>> fixed sources. This is why we need something like the safe parent
>>patch.
>>>>
>>>> [1]
>>http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/332607.html
>>>> [2]
>>http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/332615.html
>>>> [3]
>>http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/332608.html
>>>> [4] https://lwn.net/Articles/740994/ 
>>>> [5] https://lkml.org/lkml/2017/12/19/537
>>>>
>>>>
>>>> Sricharan R (3):
>>>>   clk: qcom: Add safe switch hook for krait mux clocks
>>>>   cpufreq: qcom: Re-organise kryo cpufreq to use it for other nvmem
>>>>     based qcom socs
>>>>   cpufreq: qcom: Add support for krait based socs
>>>>
>>>> Stephen Boyd (11):
>>>>   ARM: Add Krait L2 register accessor functions
>>>>   clk: qcom: Add support for High-Frequency PLLs (HFPLLs)
>>>>   clk: qcom: Add HFPLL driver
>>>>   dt-bindings: clock: Document qcom,hfpll
>>>>   clk: qcom: Add MSM8960/APQ8064's HFPLLs
>>>>   clk: qcom: Add IPQ806X's HFPLLs
>>>>   clk: qcom: Add support for Krait clocks
>>>>   clk: qcom: Add KPSS ACC/GCC driver
>>>>   dt-bindings: arm: Document qcom,kpss-gcc
>>>>   clk: qcom: Add Krait clock controller driver
>>>>   dt-bindings: clock: Document qcom,krait-cc
>>>>
>>>>  .../devicetree/bindings/arm/msm/qcom,kpss-acc.txt  |  19 +
>>>>  .../devicetree/bindings/arm/msm/qcom,kpss-gcc.txt  |  44 +++
>>>>  .../devicetree/bindings/clock/qcom,hfpll.txt       |  60 ++++
>>>>  .../devicetree/bindings/clock/qcom,krait-cc.txt    |  34 ++
>>>>  .../{kryo-cpufreq.txt => qcom-nvmem-cpufreq.txt}   |   7 +-
>>>>  arch/arm/common/Kconfig                            |   3 +
>>>>  arch/arm/common/Makefile                           |   1 +
>>>>  arch/arm/common/krait-l2-accessors.c               |  48 +++
>>>>  arch/arm/include/asm/krait-l2-accessors.h          |   9 +
>>>>  drivers/clk/qcom/Kconfig                           |  28 ++
>>>>  drivers/clk/qcom/Makefile                          |   5 +
>>>>  drivers/clk/qcom/clk-hfpll.c                       | 244
>>+++++++++++++
>>>>  drivers/clk/qcom/clk-hfpll.h                       |  44 +++
>>>>  drivers/clk/qcom/clk-krait.c                       | 126 +++++++
>>>>  drivers/clk/qcom/clk-krait.h                       |  40 +++
>>>>  drivers/clk/qcom/gcc-ipq806x.c                     |  82 +++++
>>>>  drivers/clk/qcom/gcc-msm8960.c                     | 172 +++++++++
>>>>  drivers/clk/qcom/hfpll.c                           |  96 +++++
>>>>  drivers/clk/qcom/kpss-xcc.c                        |  87 +++++
>>>>  drivers/clk/qcom/krait-cc.c                        | 397
>>+++++++++++++++++++++
>>>>  drivers/cpufreq/Kconfig.arm                        |   6 +-
>>>>  drivers/cpufreq/Makefile                           |   2 +-
>>>>  drivers/cpufreq/cpufreq-dt-platdev.c               |   5 +
>>>>  drivers/cpufreq/qcom-cpufreq-kryo.c                | 232
>>------------
>>>>  drivers/cpufreq/qcom-cpufreq-nvmem.c               | 387
>>++++++++++++++++++++
>>>>  include/dt-bindings/clock/qcom,gcc-msm8960.h       |   2 +
>>>>  26 files changed, 1941 insertions(+), 239 deletions(-)
>>>>  create mode 100644
>>Documentation/devicetree/bindings/arm/msm/qcom,kpss-gcc.txt
>>>>  create mode 100644
>>Documentation/devicetree/bindings/clock/qcom,hfpll.txt
>>>>  create mode 100644
>>Documentation/devicetree/bindings/clock/qcom,krait-cc.txt
>>>>  rename Documentation/devicetree/bindings/opp/{kryo-cpufreq.txt =>
>>qcom-nvmem-cpufreq.txt} (98%)
>>>>  create mode 100644 arch/arm/common/krait-l2-accessors.c
>>>>  create mode 100644 arch/arm/include/asm/krait-l2-accessors.h
>>>>  create mode 100644 drivers/clk/qcom/clk-hfpll.c
>>>>  create mode 100644 drivers/clk/qcom/clk-hfpll.h
>>>>  create mode 100644 drivers/clk/qcom/clk-krait.c
>>>>  create mode 100644 drivers/clk/qcom/clk-krait.h
>>>>  create mode 100644 drivers/clk/qcom/hfpll.c
>>>>  create mode 100644 drivers/clk/qcom/kpss-xcc.c
>>>>  create mode 100644 drivers/clk/qcom/krait-cc.c
>>>>  delete mode 100644 drivers/cpufreq/qcom-cpufreq-kryo.c
>>>>  create mode 100644 drivers/cpufreq/qcom-cpufreq-nvmem.c
>>>>
>>>
Sricharan Ramabadhran Sept. 20, 2018, 1:01 p.m. UTC | #5
On 9/20/2018 1:54 AM, Craig wrote:
> Yup, this patch seems to have fixed the higher frequencies from the quick test I did.
> 
  Thanks !!. Can i take that as Craig Tatlor <ctatlor97@gmail.com> ?

Regards,
 Sricharan

       tested-by: 
> On 7 September 2018 15:28:53 BST, Craig Tatlor <ctatlor97@gmail.com> wrote:
>>
>>
>> On 7 September 2018 10:57:34 BST, Sricharan R
>> <sricharan@codeaurora.org> wrote:
>>> Hi Craig,
>>>
>>>
>>>>> [v12]
>>>>>   * Added my signed-off that was missing in some patches.
>>>>>   * Added Bjorn's acked that i missed earlier.
>>>>>
>>>>
>>>>   Can you give this a try on your 8974 device and check if the
>>>>   pvs version reporting, scaling for higher frequencies are fine ?
>>>>   Sorry, i could not get hold of a 8974 device. So in-case if you
>>> still
>>>>   have the issues with higher frequencies, can you give a quick
>> debug
>>>>   and report. That would be of great help.
>>>>
>>>   Ping on this ..
>>
>> Hi, didn't see your last message,
>>
>> Will have a try on mine in the weekend and report back.
>>>
>>> Regards,
>>> Sricharan
>>>
>>>> Regards,
>>>>  Sricharan
>>>>
>>>>
>>>>> [v11]
>>>>>   * Dropped patch 13 and 14 from v10 and
>>>>>     merged the qcom-cpufreq-krait driver to the existing
>>> qcom-cpufreq-kryo.c
>>>>>   * Rebased on top of clk-next
>>>>>   * Fixed a bug while populating the pvs version for krait.
>>>>>
>>>>> [v10]
>>>>>   * Addressed Stephen's comments to add clocks bindings properties
>>>>>     to the newly introduced nodes.
>>>>>   * Added a change to include opp-supported-hw to qcom-cpufreq.c
>>>>>   * Rebased on top of clk-next
>>>>>   * Although there were minor changes to bindings and the driver
>>>>>     retained the acked-by tags from Rob and Viresh respectively.   
>>
>>>>>
>>>>> [v9]
>>>>>   * Fixed a rebase issue in Makefile and added Tag from Robh.
>>>>>
>>>>> [v8]
>>>>>   * Fixed a bug in path#14 pointed out by Viresh and also added
>>> tags.
>>>>>     No change in any other patch.
>>>>>
>>>>> [v7]
>>>>>   * Fixed comments from Viresh for cleaning up the error handling
>>>>>     in qcom-cpufreq.c. Also changed the init function to lateinit
>>>>>     call. This is required because nvmem which gets initialised
>> with
>>>>>     module_init needs to go first.
>>>>>   * Fixed Rob's comments for bindings documentation
>>>>>   * Fixed kbuild build issue in clk-lpc32xx.c
>>>>>   * Rebased on top of clk-next
>>>>>
>>>>> [v6]
>>>>>   * Adrressed comments from Viresh for patch #14 in v5 [5]
>>>>>   * Introduced a new binding operating-points-v2-krait-cpu
>>>>>     as per discussion with Rob
>>>>>   * Added Review tags
>>>>>
>>>>> [v5]
>>>>>   * Addressed comments from Rob for bindings
>>>>>   * Addressed comments from Viresh to use dev_pm_opp_set_prop_name,
>>> accordingly
>>>>>     dropped patch #12 and corrected patch #11 from previous patch
>>> set in [4]
>>>>>   * Converted to use #spdx tags for newly introduced files
>>>>>
>>>>> Mostly a resend of the v3 posted by Stephen quite some time back
>> [1]
>>>>> except for few changes.
>>>>>   Based on reading some feedback from list,
>>>>>   * Dropped the patch "clk: Add safe switch hook" from v3 [2].
>>>>>     Now this is taken care by patch#10 in this series only for
>>> Krait.
>>>>>   * Dropped the path "clk: Avoid sending high rates to downstream
>>>>> 		      clocks during set_rate" from v3 [3].
>>>>>   * Rebased on top of clk-next.
>>>>>   * Dropped the DT update from the series. Will send separately
>>>>>   * Now with cpufreq-dt+opp supporting voltage scaling, registering
>>> the
>>>>>     krait cpu supplies in DT should be sufficient. But one issue
>> is,
>>>>>     the qcom-cpufreq drivers reads the efuse and based on that
>>> registers
>>>>>     the opp data and then registers the cpufreq-dt device. So when
>>>>>     cpufreq-dt driver probes and registers the regulator to the OPP
>>> framework,
>>>>>     it expects that the opp data for the device should not be
>>> registered before
>>>>>     the regulator. Will send a RFC patch removing that check, to
>>> find out the
>>>>>     right way of doing it.
>>>>>
>>>>> These patches provide cpufreq scaling on devices with Krait CPUs.
>>>>> In Krait CPU designs there's one PLL and two muxes per CPU,
>> allowing
>>>>> us to switch CPU frequencies independently.
>>>>>
>>>>> 				 secondary
>>>>> 	 +-----+                    +
>>>>> 	 | QSB |-------+------------|\
>>>>> 	 +-----+       |            | |-+
>>>>> 		       |    +-------|/  |
>>>>> 		       |    |       +   |
>>>>> 	 +-----+       |    |           |
>>>>> 	 | PLL |----+-------+           |   primary
>>>>> 	 +-----+    |  |                |     +
>>>>> 		    |  |                +-----|\       +------+
>>>>> 	 +-------+  |  |                      | \      |      |
>>>>> 	 | HFPLL |----------+-----------------|  |-----| CPU0 |
>>>>> 	 +-------+  |  |    |                 |  |     |      |
>>>>> 		    |  |    | +-----+         | /      +------+
>>>>> 		    |  |    +-| / 2 |---------|/
>>>>> 		    |  |      +-----+         +
>>>>> 		    |  |         secondary
>>>>> 		    |  |            +
>>>>> 		    |  +------------|\
>>>>> 		    |               | |-+
>>>>> 		    +---------------|/  |   primary
>>>>> 				    +   |     +
>>>>> 					+-----|\       +------+
>>>>> 	 +-------+                            | \      |      |
>>>>> 	 | HFPLL |----------------------------|  |-----| CPU1 |
>>>>> 	 +-------+          |                 |  |     |      |
>>>>> 			    | +-----+         | /      +------+
>>>>> 			    +-| / 2 |---------|/
>>>>> 			      +-----+         +
>>>>>
>>>>> To support this in the common clock framework we model the muxes,
>>>>> dividers, and PLLs as different clocks. CPUfreq only interacts
>>>>> with the primary mux (farthest right in the diagram). When CPUfreq
>>>>> sets a rate, the mux code finds the best parent that can provide
>> the
>>> rate.
>>>>> Due to the design, QSB and the top PLL are always a fixed rate and
>>> thus
>>>>> only support one frequency each. These sources provide the lowest
>>>>> frequencies for the CPUs. The HFPLLs are where we can make the CPU
>>> go
>>>>> faster (GHz range). Sometimes we need to run the HFPLL twice as
>>>>> fast and divide it by two to get a particular frequency.
>>>>>
>>>>> When switching rates we can't leave the CPU clocked by the HFPLL
>>> because
>>>>> we need to turn off the output of the PLL when changing its
>>> frequency.
>>>>> This means we have to switch over to the secondary mux and use one
>>> of the
>>>>> fixed sources. This is why we need something like the safe parent
>>> patch.
>>>>>
>>>>> [1]
>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/332607.html
>>>>> [2]
>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/332615.html
>>>>> [3]
>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/332608.html
>>>>> [4] https://lwn.net/Articles/740994/ 
>>>>> [5] https://lkml.org/lkml/2017/12/19/537
>>>>>
>>>>>
>>>>> Sricharan R (3):
>>>>>   clk: qcom: Add safe switch hook for krait mux clocks
>>>>>   cpufreq: qcom: Re-organise kryo cpufreq to use it for other nvmem
>>>>>     based qcom socs
>>>>>   cpufreq: qcom: Add support for krait based socs
>>>>>
>>>>> Stephen Boyd (11):
>>>>>   ARM: Add Krait L2 register accessor functions
>>>>>   clk: qcom: Add support for High-Frequency PLLs (HFPLLs)
>>>>>   clk: qcom: Add HFPLL driver
>>>>>   dt-bindings: clock: Document qcom,hfpll
>>>>>   clk: qcom: Add MSM8960/APQ8064's HFPLLs
>>>>>   clk: qcom: Add IPQ806X's HFPLLs
>>>>>   clk: qcom: Add support for Krait clocks
>>>>>   clk: qcom: Add KPSS ACC/GCC driver
>>>>>   dt-bindings: arm: Document qcom,kpss-gcc
>>>>>   clk: qcom: Add Krait clock controller driver
>>>>>   dt-bindings: clock: Document qcom,krait-cc
>>>>>
>>>>>  .../devicetree/bindings/arm/msm/qcom,kpss-acc.txt  |  19 +
>>>>>  .../devicetree/bindings/arm/msm/qcom,kpss-gcc.txt  |  44 +++
>>>>>  .../devicetree/bindings/clock/qcom,hfpll.txt       |  60 ++++
>>>>>  .../devicetree/bindings/clock/qcom,krait-cc.txt    |  34 ++
>>>>>  .../{kryo-cpufreq.txt => qcom-nvmem-cpufreq.txt}   |   7 +-
>>>>>  arch/arm/common/Kconfig                            |   3 +
>>>>>  arch/arm/common/Makefile                           |   1 +
>>>>>  arch/arm/common/krait-l2-accessors.c               |  48 +++
>>>>>  arch/arm/include/asm/krait-l2-accessors.h          |   9 +
>>>>>  drivers/clk/qcom/Kconfig                           |  28 ++
>>>>>  drivers/clk/qcom/Makefile                          |   5 +
>>>>>  drivers/clk/qcom/clk-hfpll.c                       | 244
>>> +++++++++++++
>>>>>  drivers/clk/qcom/clk-hfpll.h                       |  44 +++
>>>>>  drivers/clk/qcom/clk-krait.c                       | 126 +++++++
>>>>>  drivers/clk/qcom/clk-krait.h                       |  40 +++
>>>>>  drivers/clk/qcom/gcc-ipq806x.c                     |  82 +++++
>>>>>  drivers/clk/qcom/gcc-msm8960.c                     | 172 +++++++++
>>>>>  drivers/clk/qcom/hfpll.c                           |  96 +++++
>>>>>  drivers/clk/qcom/kpss-xcc.c                        |  87 +++++
>>>>>  drivers/clk/qcom/krait-cc.c                        | 397
>>> +++++++++++++++++++++
>>>>>  drivers/cpufreq/Kconfig.arm                        |   6 +-
>>>>>  drivers/cpufreq/Makefile                           |   2 +-
>>>>>  drivers/cpufreq/cpufreq-dt-platdev.c               |   5 +
>>>>>  drivers/cpufreq/qcom-cpufreq-kryo.c                | 232
>>> ------------
>>>>>  drivers/cpufreq/qcom-cpufreq-nvmem.c               | 387
>>> ++++++++++++++++++++
>>>>>  include/dt-bindings/clock/qcom,gcc-msm8960.h       |   2 +
>>>>>  26 files changed, 1941 insertions(+), 239 deletions(-)
>>>>>  create mode 100644
>>> Documentation/devicetree/bindings/arm/msm/qcom,kpss-gcc.txt
>>>>>  create mode 100644
>>> Documentation/devicetree/bindings/clock/qcom,hfpll.txt
>>>>>  create mode 100644
>>> Documentation/devicetree/bindings/clock/qcom,krait-cc.txt
>>>>>  rename Documentation/devicetree/bindings/opp/{kryo-cpufreq.txt =>
>>> qcom-nvmem-cpufreq.txt} (98%)
>>>>>  create mode 100644 arch/arm/common/krait-l2-accessors.c
>>>>>  create mode 100644 arch/arm/include/asm/krait-l2-accessors.h
>>>>>  create mode 100644 drivers/clk/qcom/clk-hfpll.c
>>>>>  create mode 100644 drivers/clk/qcom/clk-hfpll.h
>>>>>  create mode 100644 drivers/clk/qcom/clk-krait.c
>>>>>  create mode 100644 drivers/clk/qcom/clk-krait.h
>>>>>  create mode 100644 drivers/clk/qcom/hfpll.c
>>>>>  create mode 100644 drivers/clk/qcom/kpss-xcc.c
>>>>>  create mode 100644 drivers/clk/qcom/krait-cc.c
>>>>>  delete mode 100644 drivers/cpufreq/qcom-cpufreq-kryo.c
>>>>>  create mode 100644 drivers/cpufreq/qcom-cpufreq-nvmem.c
>>>>>
>>>>
>
Sricharan Ramabadhran Sept. 20, 2018, 1:03 p.m. UTC | #6
On 9/20/2018 1:54 AM, Craig wrote:
> Yup, this patch seems to have fixed the higher frequencies from the quick test I did.
>
      Thanks !!. Can i take that as 
          Tested-by: Craig Tatlor <ctatlor97@gmail.com>  ?

Regards,
 Sricharan
 
> On 7 September 2018 15:28:53 BST, Craig Tatlor <ctatlor97@gmail.com> wrote:
>>
>>
>> On 7 September 2018 10:57:34 BST, Sricharan R
>> <sricharan@codeaurora.org> wrote:
>>> Hi Craig,
>>>
>>>
>>>>> [v12]
>>>>>   * Added my signed-off that was missing in some patches.
>>>>>   * Added Bjorn's acked that i missed earlier.
>>>>>
>>>>
>>>>   Can you give this a try on your 8974 device and check if the
>>>>   pvs version reporting, scaling for higher frequencies are fine ?
>>>>   Sorry, i could not get hold of a 8974 device. So in-case if you
>>> still
>>>>   have the issues with higher frequencies, can you give a quick
>> debug
>>>>   and report. That would be of great help.
>>>>
>>>   Ping on this ..
>>
>> Hi, didn't see your last message,
>>
>> Will have a try on mine in the weekend and report back.
>>>
>>> Regards,
>>> Sricharan
>>>
>>>> Regards,
>>>>  Sricharan
>>>>
>>>>
>>>>> [v11]
>>>>>   * Dropped patch 13 and 14 from v10 and
>>>>>     merged the qcom-cpufreq-krait driver to the existing
>>> qcom-cpufreq-kryo.c
>>>>>   * Rebased on top of clk-next
>>>>>   * Fixed a bug while populating the pvs version for krait.
>>>>>
>>>>> [v10]
>>>>>   * Addressed Stephen's comments to add clocks bindings properties
>>>>>     to the newly introduced nodes.
>>>>>   * Added a change to include opp-supported-hw to qcom-cpufreq.c
>>>>>   * Rebased on top of clk-next
>>>>>   * Although there were minor changes to bindings and the driver
>>>>>     retained the acked-by tags from Rob and Viresh respectively.   
>>
>>>>>
>>>>> [v9]
>>>>>   * Fixed a rebase issue in Makefile and added Tag from Robh.
>>>>>
>>>>> [v8]
>>>>>   * Fixed a bug in path#14 pointed out by Viresh and also added
>>> tags.
>>>>>     No change in any other patch.
>>>>>
>>>>> [v7]
>>>>>   * Fixed comments from Viresh for cleaning up the error handling
>>>>>     in qcom-cpufreq.c. Also changed the init function to lateinit
>>>>>     call. This is required because nvmem which gets initialised
>> with
>>>>>     module_init needs to go first.
>>>>>   * Fixed Rob's comments for bindings documentation
>>>>>   * Fixed kbuild build issue in clk-lpc32xx.c
>>>>>   * Rebased on top of clk-next
>>>>>
>>>>> [v6]
>>>>>   * Adrressed comments from Viresh for patch #14 in v5 [5]
>>>>>   * Introduced a new binding operating-points-v2-krait-cpu
>>>>>     as per discussion with Rob
>>>>>   * Added Review tags
>>>>>
>>>>> [v5]
>>>>>   * Addressed comments from Rob for bindings
>>>>>   * Addressed comments from Viresh to use dev_pm_opp_set_prop_name,
>>> accordingly
>>>>>     dropped patch #12 and corrected patch #11 from previous patch
>>> set in [4]
>>>>>   * Converted to use #spdx tags for newly introduced files
>>>>>
>>>>> Mostly a resend of the v3 posted by Stephen quite some time back
>> [1]
>>>>> except for few changes.
>>>>>   Based on reading some feedback from list,
>>>>>   * Dropped the patch "clk: Add safe switch hook" from v3 [2].
>>>>>     Now this is taken care by patch#10 in this series only for
>>> Krait.
>>>>>   * Dropped the path "clk: Avoid sending high rates to downstream
>>>>> 		      clocks during set_rate" from v3 [3].
>>>>>   * Rebased on top of clk-next.
>>>>>   * Dropped the DT update from the series. Will send separately
>>>>>   * Now with cpufreq-dt+opp supporting voltage scaling, registering
>>> the
>>>>>     krait cpu supplies in DT should be sufficient. But one issue
>> is,
>>>>>     the qcom-cpufreq drivers reads the efuse and based on that
>>> registers
>>>>>     the opp data and then registers the cpufreq-dt device. So when
>>>>>     cpufreq-dt driver probes and registers the regulator to the OPP
>>> framework,
>>>>>     it expects that the opp data for the device should not be
>>> registered before
>>>>>     the regulator. Will send a RFC patch removing that check, to
>>> find out the
>>>>>     right way of doing it.
>>>>>
>>>>> These patches provide cpufreq scaling on devices with Krait CPUs.
>>>>> In Krait CPU designs there's one PLL and two muxes per CPU,
>> allowing
>>>>> us to switch CPU frequencies independently.
>>>>>
>>>>> 				 secondary
>>>>> 	 +-----+                    +
>>>>> 	 | QSB |-------+------------|\
>>>>> 	 +-----+       |            | |-+
>>>>> 		       |    +-------|/  |
>>>>> 		       |    |       +   |
>>>>> 	 +-----+       |    |           |
>>>>> 	 | PLL |----+-------+           |   primary
>>>>> 	 +-----+    |  |                |     +
>>>>> 		    |  |                +-----|\       +------+
>>>>> 	 +-------+  |  |                      | \      |      |
>>>>> 	 | HFPLL |----------+-----------------|  |-----| CPU0 |
>>>>> 	 +-------+  |  |    |                 |  |     |      |
>>>>> 		    |  |    | +-----+         | /      +------+
>>>>> 		    |  |    +-| / 2 |---------|/
>>>>> 		    |  |      +-----+         +
>>>>> 		    |  |         secondary
>>>>> 		    |  |            +
>>>>> 		    |  +------------|\
>>>>> 		    |               | |-+
>>>>> 		    +---------------|/  |   primary
>>>>> 				    +   |     +
>>>>> 					+-----|\       +------+
>>>>> 	 +-------+                            | \      |      |
>>>>> 	 | HFPLL |----------------------------|  |-----| CPU1 |
>>>>> 	 +-------+          |                 |  |     |      |
>>>>> 			    | +-----+         | /      +------+
>>>>> 			    +-| / 2 |---------|/
>>>>> 			      +-----+         +
>>>>>
>>>>> To support this in the common clock framework we model the muxes,
>>>>> dividers, and PLLs as different clocks. CPUfreq only interacts
>>>>> with the primary mux (farthest right in the diagram). When CPUfreq
>>>>> sets a rate, the mux code finds the best parent that can provide
>> the
>>> rate.
>>>>> Due to the design, QSB and the top PLL are always a fixed rate and
>>> thus
>>>>> only support one frequency each. These sources provide the lowest
>>>>> frequencies for the CPUs. The HFPLLs are where we can make the CPU
>>> go
>>>>> faster (GHz range). Sometimes we need to run the HFPLL twice as
>>>>> fast and divide it by two to get a particular frequency.
>>>>>
>>>>> When switching rates we can't leave the CPU clocked by the HFPLL
>>> because
>>>>> we need to turn off the output of the PLL when changing its
>>> frequency.
>>>>> This means we have to switch over to the secondary mux and use one
>>> of the
>>>>> fixed sources. This is why we need something like the safe parent
>>> patch.
>>>>>
>>>>> [1]
>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/332607.html
>>>>> [2]
>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/332615.html
>>>>> [3]
>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/332608.html
>>>>> [4] https://lwn.net/Articles/740994/ 
>>>>> [5] https://lkml.org/lkml/2017/12/19/537
>>>>>
>>>>>
>>>>> Sricharan R (3):
>>>>>   clk: qcom: Add safe switch hook for krait mux clocks
>>>>>   cpufreq: qcom: Re-organise kryo cpufreq to use it for other nvmem
>>>>>     based qcom socs
>>>>>   cpufreq: qcom: Add support for krait based socs
>>>>>
>>>>> Stephen Boyd (11):
>>>>>   ARM: Add Krait L2 register accessor functions
>>>>>   clk: qcom: Add support for High-Frequency PLLs (HFPLLs)
>>>>>   clk: qcom: Add HFPLL driver
>>>>>   dt-bindings: clock: Document qcom,hfpll
>>>>>   clk: qcom: Add MSM8960/APQ8064's HFPLLs
>>>>>   clk: qcom: Add IPQ806X's HFPLLs
>>>>>   clk: qcom: Add support for Krait clocks
>>>>>   clk: qcom: Add KPSS ACC/GCC driver
>>>>>   dt-bindings: arm: Document qcom,kpss-gcc
>>>>>   clk: qcom: Add Krait clock controller driver
>>>>>   dt-bindings: clock: Document qcom,krait-cc
>>>>>
>>>>>  .../devicetree/bindings/arm/msm/qcom,kpss-acc.txt  |  19 +
>>>>>  .../devicetree/bindings/arm/msm/qcom,kpss-gcc.txt  |  44 +++
>>>>>  .../devicetree/bindings/clock/qcom,hfpll.txt       |  60 ++++
>>>>>  .../devicetree/bindings/clock/qcom,krait-cc.txt    |  34 ++
>>>>>  .../{kryo-cpufreq.txt => qcom-nvmem-cpufreq.txt}   |   7 +-
>>>>>  arch/arm/common/Kconfig                            |   3 +
>>>>>  arch/arm/common/Makefile                           |   1 +
>>>>>  arch/arm/common/krait-l2-accessors.c               |  48 +++
>>>>>  arch/arm/include/asm/krait-l2-accessors.h          |   9 +
>>>>>  drivers/clk/qcom/Kconfig                           |  28 ++
>>>>>  drivers/clk/qcom/Makefile                          |   5 +
>>>>>  drivers/clk/qcom/clk-hfpll.c                       | 244
>>> +++++++++++++
>>>>>  drivers/clk/qcom/clk-hfpll.h                       |  44 +++
>>>>>  drivers/clk/qcom/clk-krait.c                       | 126 +++++++
>>>>>  drivers/clk/qcom/clk-krait.h                       |  40 +++
>>>>>  drivers/clk/qcom/gcc-ipq806x.c                     |  82 +++++
>>>>>  drivers/clk/qcom/gcc-msm8960.c                     | 172 +++++++++
>>>>>  drivers/clk/qcom/hfpll.c                           |  96 +++++
>>>>>  drivers/clk/qcom/kpss-xcc.c                        |  87 +++++
>>>>>  drivers/clk/qcom/krait-cc.c                        | 397
>>> +++++++++++++++++++++
>>>>>  drivers/cpufreq/Kconfig.arm                        |   6 +-
>>>>>  drivers/cpufreq/Makefile                           |   2 +-
>>>>>  drivers/cpufreq/cpufreq-dt-platdev.c               |   5 +
>>>>>  drivers/cpufreq/qcom-cpufreq-kryo.c                | 232
>>> ------------
>>>>>  drivers/cpufreq/qcom-cpufreq-nvmem.c               | 387
>>> ++++++++++++++++++++
>>>>>  include/dt-bindings/clock/qcom,gcc-msm8960.h       |   2 +
>>>>>  26 files changed, 1941 insertions(+), 239 deletions(-)
>>>>>  create mode 100644
>>> Documentation/devicetree/bindings/arm/msm/qcom,kpss-gcc.txt
>>>>>  create mode 100644
>>> Documentation/devicetree/bindings/clock/qcom,hfpll.txt
>>>>>  create mode 100644
>>> Documentation/devicetree/bindings/clock/qcom,krait-cc.txt
>>>>>  rename Documentation/devicetree/bindings/opp/{kryo-cpufreq.txt =>
>>> qcom-nvmem-cpufreq.txt} (98%)
>>>>>  create mode 100644 arch/arm/common/krait-l2-accessors.c
>>>>>  create mode 100644 arch/arm/include/asm/krait-l2-accessors.h
>>>>>  create mode 100644 drivers/clk/qcom/clk-hfpll.c
>>>>>  create mode 100644 drivers/clk/qcom/clk-hfpll.h
>>>>>  create mode 100644 drivers/clk/qcom/clk-krait.c
>>>>>  create mode 100644 drivers/clk/qcom/clk-krait.h
>>>>>  create mode 100644 drivers/clk/qcom/hfpll.c
>>>>>  create mode 100644 drivers/clk/qcom/kpss-xcc.c
>>>>>  create mode 100644 drivers/clk/qcom/krait-cc.c
>>>>>  delete mode 100644 drivers/cpufreq/qcom-cpufreq-kryo.c
>>>>>  create mode 100644 drivers/cpufreq/qcom-cpufreq-nvmem.c
>>>>>
>>>>
>
Craig Tatlor Sept. 20, 2018, 2:27 p.m. UTC | #7
On 20 September 2018 14:01:57 BST, Sricharan R <sricharan@codeaurora.org> wrote:
>
>
>On 9/20/2018 1:54 AM, Craig wrote:
>> Yup, this patch seems to have fixed the higher frequencies from the
>quick test I did.
>> 
>  Thanks !!. Can i take that as Craig Tatlor <ctatlor97@gmail.com> ?
Sure, no problem
>
>Regards,
> Sricharan
>
>       tested-by: 
>> On 7 September 2018 15:28:53 BST, Craig Tatlor <ctatlor97@gmail.com>
>wrote:
>>>
>>>
>>> On 7 September 2018 10:57:34 BST, Sricharan R
>>> <sricharan@codeaurora.org> wrote:
>>>> Hi Craig,
>>>>
>>>>
>>>>>> [v12]
>>>>>>   * Added my signed-off that was missing in some patches.
>>>>>>   * Added Bjorn's acked that i missed earlier.
>>>>>>
>>>>>
>>>>>   Can you give this a try on your 8974 device and check if the
>>>>>   pvs version reporting, scaling for higher frequencies are fine ?
>>>>>   Sorry, i could not get hold of a 8974 device. So in-case if you
>>>> still
>>>>>   have the issues with higher frequencies, can you give a quick
>>> debug
>>>>>   and report. That would be of great help.
>>>>>
>>>>   Ping on this ..
>>>
>>> Hi, didn't see your last message,
>>>
>>> Will have a try on mine in the weekend and report back.
>>>>
>>>> Regards,
>>>> Sricharan
>>>>
>>>>> Regards,
>>>>>  Sricharan
>>>>>
>>>>>
>>>>>> [v11]
>>>>>>   * Dropped patch 13 and 14 from v10 and
>>>>>>     merged the qcom-cpufreq-krait driver to the existing
>>>> qcom-cpufreq-kryo.c
>>>>>>   * Rebased on top of clk-next
>>>>>>   * Fixed a bug while populating the pvs version for krait.
>>>>>>
>>>>>> [v10]
>>>>>>   * Addressed Stephen's comments to add clocks bindings
>properties
>>>>>>     to the newly introduced nodes.
>>>>>>   * Added a change to include opp-supported-hw to qcom-cpufreq.c
>>>>>>   * Rebased on top of clk-next
>>>>>>   * Although there were minor changes to bindings and the driver
>>>>>>     retained the acked-by tags from Rob and Viresh respectively. 
> 
>>>
>>>>>>
>>>>>> [v9]
>>>>>>   * Fixed a rebase issue in Makefile and added Tag from Robh.
>>>>>>
>>>>>> [v8]
>>>>>>   * Fixed a bug in path#14 pointed out by Viresh and also added
>>>> tags.
>>>>>>     No change in any other patch.
>>>>>>
>>>>>> [v7]
>>>>>>   * Fixed comments from Viresh for cleaning up the error handling
>>>>>>     in qcom-cpufreq.c. Also changed the init function to lateinit
>>>>>>     call. This is required because nvmem which gets initialised
>>> with
>>>>>>     module_init needs to go first.
>>>>>>   * Fixed Rob's comments for bindings documentation
>>>>>>   * Fixed kbuild build issue in clk-lpc32xx.c
>>>>>>   * Rebased on top of clk-next
>>>>>>
>>>>>> [v6]
>>>>>>   * Adrressed comments from Viresh for patch #14 in v5 [5]
>>>>>>   * Introduced a new binding operating-points-v2-krait-cpu
>>>>>>     as per discussion with Rob
>>>>>>   * Added Review tags
>>>>>>
>>>>>> [v5]
>>>>>>   * Addressed comments from Rob for bindings
>>>>>>   * Addressed comments from Viresh to use
>dev_pm_opp_set_prop_name,
>>>> accordingly
>>>>>>     dropped patch #12 and corrected patch #11 from previous patch
>>>> set in [4]
>>>>>>   * Converted to use #spdx tags for newly introduced files
>>>>>>
>>>>>> Mostly a resend of the v3 posted by Stephen quite some time back
>>> [1]
>>>>>> except for few changes.
>>>>>>   Based on reading some feedback from list,
>>>>>>   * Dropped the patch "clk: Add safe switch hook" from v3 [2].
>>>>>>     Now this is taken care by patch#10 in this series only for
>>>> Krait.
>>>>>>   * Dropped the path "clk: Avoid sending high rates to downstream
>>>>>> 		      clocks during set_rate" from v3 [3].
>>>>>>   * Rebased on top of clk-next.
>>>>>>   * Dropped the DT update from the series. Will send separately
>>>>>>   * Now with cpufreq-dt+opp supporting voltage scaling,
>registering
>>>> the
>>>>>>     krait cpu supplies in DT should be sufficient. But one issue
>>> is,
>>>>>>     the qcom-cpufreq drivers reads the efuse and based on that
>>>> registers
>>>>>>     the opp data and then registers the cpufreq-dt device. So
>when
>>>>>>     cpufreq-dt driver probes and registers the regulator to the
>OPP
>>>> framework,
>>>>>>     it expects that the opp data for the device should not be
>>>> registered before
>>>>>>     the regulator. Will send a RFC patch removing that check, to
>>>> find out the
>>>>>>     right way of doing it.
>>>>>>
>>>>>> These patches provide cpufreq scaling on devices with Krait CPUs.
>>>>>> In Krait CPU designs there's one PLL and two muxes per CPU,
>>> allowing
>>>>>> us to switch CPU frequencies independently.
>>>>>>
>>>>>> 				 secondary
>>>>>> 	 +-----+                    +
>>>>>> 	 | QSB |-------+------------|\
>>>>>> 	 +-----+       |            | |-+
>>>>>> 		       |    +-------|/  |
>>>>>> 		       |    |       +   |
>>>>>> 	 +-----+       |    |           |
>>>>>> 	 | PLL |----+-------+           |   primary
>>>>>> 	 +-----+    |  |                |     +
>>>>>> 		    |  |                +-----|\       +------+
>>>>>> 	 +-------+  |  |                      | \      |      |
>>>>>> 	 | HFPLL |----------+-----------------|  |-----| CPU0 |
>>>>>> 	 +-------+  |  |    |                 |  |     |      |
>>>>>> 		    |  |    | +-----+         | /      +------+
>>>>>> 		    |  |    +-| / 2 |---------|/
>>>>>> 		    |  |      +-----+         +
>>>>>> 		    |  |         secondary
>>>>>> 		    |  |            +
>>>>>> 		    |  +------------|\
>>>>>> 		    |               | |-+
>>>>>> 		    +---------------|/  |   primary
>>>>>> 				    +   |     +
>>>>>> 					+-----|\       +------+
>>>>>> 	 +-------+                            | \      |      |
>>>>>> 	 | HFPLL |----------------------------|  |-----| CPU1 |
>>>>>> 	 +-------+          |                 |  |     |      |
>>>>>> 			    | +-----+         | /      +------+
>>>>>> 			    +-| / 2 |---------|/
>>>>>> 			      +-----+         +
>>>>>>
>>>>>> To support this in the common clock framework we model the muxes,
>>>>>> dividers, and PLLs as different clocks. CPUfreq only interacts
>>>>>> with the primary mux (farthest right in the diagram). When
>CPUfreq
>>>>>> sets a rate, the mux code finds the best parent that can provide
>>> the
>>>> rate.
>>>>>> Due to the design, QSB and the top PLL are always a fixed rate
>and
>>>> thus
>>>>>> only support one frequency each. These sources provide the lowest
>>>>>> frequencies for the CPUs. The HFPLLs are where we can make the
>CPU
>>>> go
>>>>>> faster (GHz range). Sometimes we need to run the HFPLL twice as
>>>>>> fast and divide it by two to get a particular frequency.
>>>>>>
>>>>>> When switching rates we can't leave the CPU clocked by the HFPLL
>>>> because
>>>>>> we need to turn off the output of the PLL when changing its
>>>> frequency.
>>>>>> This means we have to switch over to the secondary mux and use
>one
>>>> of the
>>>>>> fixed sources. This is why we need something like the safe parent
>>>> patch.
>>>>>>
>>>>>> [1]
>>>>
>http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/332607.html
>>>>>> [2]
>>>>
>http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/332615.html
>>>>>> [3]
>>>>
>http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/332608.html
>>>>>> [4] https://lwn.net/Articles/740994/ 
>>>>>> [5] https://lkml.org/lkml/2017/12/19/537
>>>>>>
>>>>>>
>>>>>> Sricharan R (3):
>>>>>>   clk: qcom: Add safe switch hook for krait mux clocks
>>>>>>   cpufreq: qcom: Re-organise kryo cpufreq to use it for other
>nvmem
>>>>>>     based qcom socs
>>>>>>   cpufreq: qcom: Add support for krait based socs
>>>>>>
>>>>>> Stephen Boyd (11):
>>>>>>   ARM: Add Krait L2 register accessor functions
>>>>>>   clk: qcom: Add support for High-Frequency PLLs (HFPLLs)
>>>>>>   clk: qcom: Add HFPLL driver
>>>>>>   dt-bindings: clock: Document qcom,hfpll
>>>>>>   clk: qcom: Add MSM8960/APQ8064's HFPLLs
>>>>>>   clk: qcom: Add IPQ806X's HFPLLs
>>>>>>   clk: qcom: Add support for Krait clocks
>>>>>>   clk: qcom: Add KPSS ACC/GCC driver
>>>>>>   dt-bindings: arm: Document qcom,kpss-gcc
>>>>>>   clk: qcom: Add Krait clock controller driver
>>>>>>   dt-bindings: clock: Document qcom,krait-cc
>>>>>>
>>>>>>  .../devicetree/bindings/arm/msm/qcom,kpss-acc.txt  |  19 +
>>>>>>  .../devicetree/bindings/arm/msm/qcom,kpss-gcc.txt  |  44 +++
>>>>>>  .../devicetree/bindings/clock/qcom,hfpll.txt       |  60 ++++
>>>>>>  .../devicetree/bindings/clock/qcom,krait-cc.txt    |  34 ++
>>>>>>  .../{kryo-cpufreq.txt => qcom-nvmem-cpufreq.txt}   |   7 +-
>>>>>>  arch/arm/common/Kconfig                            |   3 +
>>>>>>  arch/arm/common/Makefile                           |   1 +
>>>>>>  arch/arm/common/krait-l2-accessors.c               |  48 +++
>>>>>>  arch/arm/include/asm/krait-l2-accessors.h          |   9 +
>>>>>>  drivers/clk/qcom/Kconfig                           |  28 ++
>>>>>>  drivers/clk/qcom/Makefile                          |   5 +
>>>>>>  drivers/clk/qcom/clk-hfpll.c                       | 244
>>>> +++++++++++++
>>>>>>  drivers/clk/qcom/clk-hfpll.h                       |  44 +++
>>>>>>  drivers/clk/qcom/clk-krait.c                       | 126 +++++++
>>>>>>  drivers/clk/qcom/clk-krait.h                       |  40 +++
>>>>>>  drivers/clk/qcom/gcc-ipq806x.c                     |  82 +++++
>>>>>>  drivers/clk/qcom/gcc-msm8960.c                     | 172
>+++++++++
>>>>>>  drivers/clk/qcom/hfpll.c                           |  96 +++++
>>>>>>  drivers/clk/qcom/kpss-xcc.c                        |  87 +++++
>>>>>>  drivers/clk/qcom/krait-cc.c                        | 397
>>>> +++++++++++++++++++++
>>>>>>  drivers/cpufreq/Kconfig.arm                        |   6 +-
>>>>>>  drivers/cpufreq/Makefile                           |   2 +-
>>>>>>  drivers/cpufreq/cpufreq-dt-platdev.c               |   5 +
>>>>>>  drivers/cpufreq/qcom-cpufreq-kryo.c                | 232
>>>> ------------
>>>>>>  drivers/cpufreq/qcom-cpufreq-nvmem.c               | 387
>>>> ++++++++++++++++++++
>>>>>>  include/dt-bindings/clock/qcom,gcc-msm8960.h       |   2 +
>>>>>>  26 files changed, 1941 insertions(+), 239 deletions(-)
>>>>>>  create mode 100644
>>>> Documentation/devicetree/bindings/arm/msm/qcom,kpss-gcc.txt
>>>>>>  create mode 100644
>>>> Documentation/devicetree/bindings/clock/qcom,hfpll.txt
>>>>>>  create mode 100644
>>>> Documentation/devicetree/bindings/clock/qcom,krait-cc.txt
>>>>>>  rename Documentation/devicetree/bindings/opp/{kryo-cpufreq.txt
>=>
>>>> qcom-nvmem-cpufreq.txt} (98%)
>>>>>>  create mode 100644 arch/arm/common/krait-l2-accessors.c
>>>>>>  create mode 100644 arch/arm/include/asm/krait-l2-accessors.h
>>>>>>  create mode 100644 drivers/clk/qcom/clk-hfpll.c
>>>>>>  create mode 100644 drivers/clk/qcom/clk-hfpll.h
>>>>>>  create mode 100644 drivers/clk/qcom/clk-krait.c
>>>>>>  create mode 100644 drivers/clk/qcom/clk-krait.h
>>>>>>  create mode 100644 drivers/clk/qcom/hfpll.c
>>>>>>  create mode 100644 drivers/clk/qcom/kpss-xcc.c
>>>>>>  create mode 100644 drivers/clk/qcom/krait-cc.c
>>>>>>  delete mode 100644 drivers/cpufreq/qcom-cpufreq-kryo.c
>>>>>>  create mode 100644 drivers/cpufreq/qcom-cpufreq-nvmem.c
>>>>>>
>>>>>
>>
Stephen Boyd Oct. 17, 2018, 3:44 p.m. UTC | #8
Quoting Sricharan R (2018-09-20 06:03:31)
> 
> 
> On 9/20/2018 1:54 AM, Craig wrote:
> > Yup, this patch seems to have fixed the higher frequencies from the quick test I did.
> >
>       Thanks !!. Can i take that as 
>           Tested-by: Craig Tatlor <ctatlor97@gmail.com>  ?
> 

Is this patch series going to be resent?
Stephen Boyd Oct. 17, 2018, 8:16 p.m. UTC | #9
Quoting Stephen Boyd (2018-10-17 08:44:12)
> Quoting Sricharan R (2018-09-20 06:03:31)
> > 
> > 
> > On 9/20/2018 1:54 AM, Craig wrote:
> > > Yup, this patch seems to have fixed the higher frequencies from the quick test I did.
> > >
> >       Thanks !!. Can i take that as 
> >           Tested-by: Craig Tatlor <ctatlor97@gmail.com>  ?
> > 
> 
> Is this patch series going to be resent?
> 

Nevermind. Looking at it I think I can apply all the clk ones and we're
good to go. If you can send a followup patch series to change the
registration and provider APIs to be clk_hw instead of clk based I would
appreciate it.
Sricharan Ramabadhran Oct. 22, 2018, 4:09 a.m. UTC | #10
Hi Stephen,

On 10/18/2018 1:46 AM, Stephen Boyd wrote:
> Quoting Stephen Boyd (2018-10-17 08:44:12)
>> Quoting Sricharan R (2018-09-20 06:03:31)
>>>
>>>
>>> On 9/20/2018 1:54 AM, Craig wrote:
>>>> Yup, this patch seems to have fixed the higher frequencies from the quick test I did.
>>>>
>>>       Thanks !!. Can i take that as 
>>>           Tested-by: Craig Tatlor <ctatlor97@gmail.com>  ?
>>>
>>
>> Is this patch series going to be resent?
>>
> 
> Nevermind. Looking at it I think I can apply all the clk ones and we're
> good to go. If you can send a followup patch series to change the
> registration and provider APIs to be clk_hw instead of clk based I would
> appreciate it.
> 

Sorry for the late response. Was away.
Only pending thing was separating out the binding documentation for the cpu-freq
driver and fixing the text in documentation.  That means, yes its fine to merge
the clk ones as you said. I will resend that. Also, will send a follow up series for clk_hw to
clk change as you mentioned separately.

Regards,
 Sricharan
Niklas Cassel Oct. 22, 2018, 3:30 p.m. UTC | #11
On Mon, Oct 22, 2018 at 09:39:03AM +0530, Sricharan R wrote:
> Hi Stephen,
> 
> On 10/18/2018 1:46 AM, Stephen Boyd wrote:
> > Quoting Stephen Boyd (2018-10-17 08:44:12)
> >> Quoting Sricharan R (2018-09-20 06:03:31)
> >>>
> >>>
> >>> On 9/20/2018 1:54 AM, Craig wrote:
> >>>> Yup, this patch seems to have fixed the higher frequencies from the quick test I did.
> >>>>
> >>>       Thanks !!. Can i take that as 
> >>>           Tested-by: Craig Tatlor <ctatlor97@gmail.com>  ?
> >>>
> >>
> >> Is this patch series going to be resent?
> >>
> > 
> > Nevermind. Looking at it I think I can apply all the clk ones and we're
> > good to go. If you can send a followup patch series to change the
> > registration and provider APIs to be clk_hw instead of clk based I would
> > appreciate it.
> > 
> 
> Sorry for the late response. Was away.
> Only pending thing was separating out the binding documentation for the cpu-freq
> driver and fixing the text in documentation.  That means, yes its fine to merge
> the clk ones as you said. I will resend that. Also, will send a follow up series for clk_hw to
> clk change as you mentioned separately.

Hello Sricharan,

Great to see that the clk parts has been marged to clk-next!

Are you also planning on sending out a new version of the cpufreq driver
consolidation parts?

I'm planning on extending your consilidated cpufreq driver with support
for msm8916 (Cortex-A53), where I plan to read PVS/speedbin, in order to
set opp_supported_hw(), and also register with cpufreq (since Viresh/Ulf
suggested that we shouldn't register with cpufreq in the CPR power-domain
driver).


Kind regards,
Niklas
Sricharan Ramabadhran Oct. 24, 2018, 4:11 a.m. UTC | #12
Hi Niklas,

On 10/22/2018 9:00 PM, Niklas Cassel wrote:
> On Mon, Oct 22, 2018 at 09:39:03AM +0530, Sricharan R wrote:
>> Hi Stephen,
>>
>> On 10/18/2018 1:46 AM, Stephen Boyd wrote:
>>> Quoting Stephen Boyd (2018-10-17 08:44:12)
>>>> Quoting Sricharan R (2018-09-20 06:03:31)
>>>>>
>>>>>
>>>>> On 9/20/2018 1:54 AM, Craig wrote:
>>>>>> Yup, this patch seems to have fixed the higher frequencies from the quick test I did.
>>>>>>
>>>>>       Thanks !!. Can i take that as 
>>>>>           Tested-by: Craig Tatlor <ctatlor97@gmail.com>  ?
>>>>>
>>>>
>>>> Is this patch series going to be resent?
>>>>
>>>
>>> Nevermind. Looking at it I think I can apply all the clk ones and we're
>>> good to go. If you can send a followup patch series to change the
>>> registration and provider APIs to be clk_hw instead of clk based I would
>>> appreciate it.
>>>
>>
>> Sorry for the late response. Was away.
>> Only pending thing was separating out the binding documentation for the cpu-freq
>> driver and fixing the text in documentation.  That means, yes its fine to merge
>> the clk ones as you said. I will resend that. Also, will send a follow up series for clk_hw to
>> clk change as you mentioned separately.
> 
> Hello Sricharan,
> 
> Great to see that the clk parts has been marged to clk-next!
> 
> Are you also planning on sending out a new version of the cpufreq driver
> consolidation parts?
> 
   yeah right, will send a new version, sometime next week.

> I'm planning on extending your consilidated cpufreq driver with support
> for msm8916 (Cortex-A53), where I plan to read PVS/speedbin, in order to
> set opp_supported_hw(), and also register with cpufreq (since Viresh/Ulf
> suggested that we shouldn't register with cpufreq in the CPR power-domain
> driver).

   ok sure.

Regards,
 Sricharan