[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <F5A89365-C613-4FE2-AD32-DC0AC6DF380B@gmail.com>
Date: Wed, 19 Sep 2018 21:24:53 +0100
From: Craig <ctatlor97@...il.com>
To: Sricharan R <sricharan@...eaurora.org>, mark.rutland@....com,
robh@...nel.org, sudeep.holla@....com, linux@....linux.org.uk,
rjw@...ysocki.net, viresh.kumar@...aro.org,
mturquette@...libre.com, linux-pm@...r.kernel.org,
sboyd@...eaurora.org, linux@...linux.org.uk,
thierry.escande@...aro.org, linux-kernel@...r.kernel.org,
david.brown@...aro.org, devicetree@...r.kernel.org,
linux-arm-msm@...r.kernel.org, andy.gross@...aro.org,
linux-soc@...r.kernel.org, linux-clk@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, niklas.cassel@...aro.org
Subject: Re: [PATCH V12 00/14] Krait clocks + Krait CPUfreq
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@...il.com> wrote:
>
>
>On 7 September 2018 10:57:34 BST, Sricharan R
><sricharan@...eaurora.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
>>>>
>>>
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Powered by blists - more mailing lists