linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sricharan R <sricharan@codeaurora.org>
To: mark.rutland@arm.com, robh@kernel.org, sudeep.holla@arm.com,
	linux@arm.linux.org.uk, ctatlor97@gmail.com, rjw@rjwysocki.net,
	viresh.kumar@linaro.org, mturquette@baylibre.com,
	linux-pm@vger.kernel.org, sboyd@codeaurora.org,
	linux@armlinux.org.uk, thierry.escande@linaro.org,
	linux-kernel@vger.kernel.org, david.brown@linaro.org,
	devicetree@vger.kernel.org, linux-arm-msm@vger.kernel.org,
	andy.gross@linaro.org, linux-soc@vger.kernel.org,
	linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	niklas.cassel@linaro.org
Subject: Re: [PATCH V12 00/14] Krait clocks + Krait CPUfreq
Date: Fri, 7 Sep 2018 15:27:34 +0530	[thread overview]
Message-ID: <d682580d-5070-0271-197f-29d988172937@codeaurora.org> (raw)
In-Reply-To: <2ae96741-94c0-ba4c-fc19-05d33179683c@codeaurora.org>

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

-- 
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

  reply	other threads:[~2018-09-07  9:57 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-14 12:12 [PATCH V12 00/14] Krait clocks + Krait CPUfreq Sricharan R
2018-08-14 12:12 ` [PATCH v12 01/14] ARM: Add Krait L2 register accessor functions Sricharan R
2018-08-14 12:12 ` [PATCH v12 02/14] clk: qcom: Add support for High-Frequency PLLs (HFPLLs) Sricharan R
2018-08-14 12:12 ` [PATCH v12 03/14] clk: qcom: Add HFPLL driver Sricharan R
2018-08-14 12:12 ` [PATCH v12 04/14] dt-bindings: clock: Document qcom,hfpll Sricharan R
2018-08-14 12:12 ` [PATCH v12 05/14] clk: qcom: Add MSM8960/APQ8064's HFPLLs Sricharan R
2018-08-14 12:12 ` [PATCH v12 06/14] clk: qcom: Add IPQ806X's HFPLLs Sricharan R
2018-08-14 12:12 ` [PATCH v12 07/14] clk: qcom: Add support for Krait clocks Sricharan R
2018-08-14 12:12 ` [PATCH v12 08/14] clk: qcom: Add KPSS ACC/GCC driver Sricharan R
2018-08-14 12:12 ` [PATCH v12 09/14] dt-bindings: arm: Document qcom,kpss-gcc Sricharan R
2018-08-14 12:12 ` [PATCH v12 10/14] clk: qcom: Add Krait clock controller driver Sricharan R
2018-08-14 12:12 ` [PATCH v12 11/14] dt-bindings: clock: Document qcom,krait-cc Sricharan R
2018-08-14 12:12 ` [PATCH v12 12/14] clk: qcom: Add safe switch hook for krait mux clocks Sricharan R
2018-08-14 12:12 ` [PATCH v12 13/14] cpufreq: qcom: Re-organise kryo cpufreq to use it for other nvmem based qcom socs Sricharan R
2018-08-17 15:09   ` Rob Herring
2018-08-20 12:45     ` Sricharan R
2018-08-14 12:12 ` [PATCH v12 14/14] cpufreq: qcom: Add support for krait based socs Sricharan R
2018-08-17 15:09   ` Rob Herring
2018-08-24 15:21   ` Niklas Cassel
2018-08-24 19:15   ` Niklas Cassel
2018-08-14 12:20 ` [PATCH V12 00/14] Krait clocks + Krait CPUfreq Sricharan R
2018-09-07  9:57   ` Sricharan R [this message]
2018-09-07 14:28     ` Craig Tatlor
2018-09-19 20:24       ` Craig
2018-09-20 13:01         ` Sricharan R
2018-09-20 14:27           ` Craig
2018-09-20 13:03         ` Sricharan R
2018-10-17 15:44           ` Stephen Boyd
2018-10-17 20:16             ` Stephen Boyd
2018-10-22  4:09               ` Sricharan R
2018-10-22 15:30                 ` Niklas Cassel
2018-10-24  4:11                   ` Sricharan R

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d682580d-5070-0271-197f-29d988172937@codeaurora.org \
    --to=sricharan@codeaurora.org \
    --cc=andy.gross@linaro.org \
    --cc=ctatlor97@gmail.com \
    --cc=david.brown@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-soc@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=linux@armlinux.org.uk \
    --cc=mark.rutland@arm.com \
    --cc=mturquette@baylibre.com \
    --cc=niklas.cassel@linaro.org \
    --cc=rjw@rjwysocki.net \
    --cc=robh@kernel.org \
    --cc=sboyd@codeaurora.org \
    --cc=sudeep.holla@arm.com \
    --cc=thierry.escande@linaro.org \
    --cc=viresh.kumar@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).