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@xxxxxxxxx> ?
Regards,
Sricharan
tested-by:
> On 7 September 2018 15:28:53 BST, Craig Tatlor <ctatlor97@xxxxxxxxx> wrote:
>>
>>
>> On 7 September 2018 10:57:34 BST, Sricharan R
>> <sricharan@xxxxxxxxxxxxxx> 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
>>>>>
>>>>
>
--
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
