Re: [PATCH V12 00/14] Krait clocks + Krait CPUfreq
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 ? > 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 -- "QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH V12 00/14] Krait clocks + Krait CPUfreq
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 ? > 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 -- "QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH V12 00/14] Krait clocks + Krait CPUfreq
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 ? > >>> > >> > >> 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
Re: [PATCH V12 00/14] Krait clocks + Krait CPUfreq
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 ? > >>> > >> > >> 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
Re: [PATCH V12 00/14] Krait clocks + Krait CPUfreq
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 ? >>> >> >> 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 -- "QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH V12 00/14] Krait clocks + Krait CPUfreq
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 ? >>> >> >> 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 -- "QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH V12 00/14] Krait clocks + Krait CPUfreq
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 ? > > > > 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.
Re: [PATCH V12 00/14] Krait clocks + Krait CPUfreq
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 ? > > > > 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.
Re: [PATCH V12 00/14] Krait clocks + Krait CPUfreq
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 ? > Is this patch series going to be resent?
Re: [PATCH V12 00/14] Krait clocks + Krait CPUfreq
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 ? > Is this patch series going to be resent?
Re: [PATCH V12 00/14] Krait clocks + Krait CPUfreq
On 20 September 2018 14:01:57 BST, Sricharan R 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 ? Sure, no problem > >Regards, > Sricharan > > tested-by: >> On 7 September 2018 15:28:53 BST, Craig Tatlor >wrote: >>> >>> >>> On 7 September 2018 10:57:34 BST, Sricharan R >>> 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
Re: [PATCH V12 00/14] Krait clocks + Krait CPUfreq
On 20 September 2018 14:01:57 BST, Sricharan R 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 ? Sure, no problem > >Regards, > Sricharan > > tested-by: >> On 7 September 2018 15:28:53 BST, Craig Tatlor >wrote: >>> >>> >>> On 7 September 2018 10:57:34 BST, Sricharan R >>> 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
Re: [PATCH V12 00/14] Krait clocks + Krait CPUfreq
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 ? Regards, Sricharan > On 7 September 2018 15:28:53 BST, Craig Tatlor wrote: >> >> >> On 7 September 2018 10:57:34 BST, Sricharan R >> 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
Re: [PATCH V12 00/14] Krait clocks + Krait CPUfreq
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 ? Regards, Sricharan > On 7 September 2018 15:28:53 BST, Craig Tatlor wrote: >> >> >> On 7 September 2018 10:57:34 BST, Sricharan R >> 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
Re: [PATCH V12 00/14] Krait clocks + Krait CPUfreq
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 ? Regards, Sricharan tested-by: > On 7 September 2018 15:28:53 BST, Craig Tatlor wrote: >> >> >> On 7 September 2018 10:57:34 BST, Sricharan R >> 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
Re: [PATCH V12 00/14] Krait clocks + Krait CPUfreq
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 ? Regards, Sricharan tested-by: > On 7 September 2018 15:28:53 BST, Craig Tatlor wrote: >> >> >> On 7 September 2018 10:57:34 BST, Sricharan R >> 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
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 wrote: > > >On 7 September 2018 10:57:34 BST, Sricharan R > 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 | |+ | +|\ | | |-+ +---|/ |
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 wrote: > > >On 7 September 2018 10:57:34 BST, Sricharan R > 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 | |+ | +|\ | | |-+ +---|/ |
Re: [PATCH V12 00/14] Krait clocks + Krait CPUfreq
On 7 September 2018 10:57:34 BST, Sricharan R 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 | >>>
Re: [PATCH V12 00/14] Krait clocks + Krait CPUfreq
On 7 September 2018 10:57:34 BST, Sricharan R 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 | >>>
Re: [PATCH V12 00/14] Krait clocks + Krait CPUfreq
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
Re: [PATCH V12 00/14] Krait clocks + Krait CPUfreq
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
Re: [PATCH V12 00/14] Krait clocks + Krait CPUfreq
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
Re: [PATCH V12 00/14] Krait clocks + Krait CPUfreq
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
[PATCH V12 00/14] Krait clocks + Krait CPUfreq
[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
[PATCH V12 00/14] Krait clocks + Krait CPUfreq
[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
