| Message ID | 1534248753-2440-1-git-send-email-sricharan@codeaurora.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | Krait clocks + Krait CPUfreq | expand |
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 >
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 >> >
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 >>> >>
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 >>>> >>>
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 >>>>> >>>> >
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 >>>>> >>>> >
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 >>>>>> >>>>> >>
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?
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.
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
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
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
[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