mbox series

[0/4] Support dynamic voltage frequency scaling inside clock controller

Message ID 20220805074935.1158098-1-jun.nie@linaro.org
Headers show
Series Support dynamic voltage frequency scaling inside clock controller | expand

Message

Jun Nie Aug. 5, 2022, 7:49 a.m. UTC 
Support dynamic voltage frequency scaling inside clock controller with
changes in clock framework. And added msm8916 as the first SoC to
support this feature.

Jun Nie (4):
  clk: Aggregate power operation in clock controller
  soc: qcom: rpmpd: Add corner power-domains states
  arm64: dts: qcom: add power domain for clk controller
  clk: qcom: gcc-msm8916: Add power domain data

 arch/arm64/boot/dts/qcom/msm8916.dtsi  |  14 +-
 drivers/clk/clk.c                      | 212 ++++++++++++++++++++++++-
 drivers/clk/qcom/gcc-msm8916.c         | 182 +++++++++++++++++++++
 include/dt-bindings/power/qcom-rpmpd.h |   8 +
 include/linux/clk-provider.h           |  62 ++++++++
 5 files changed, 470 insertions(+), 8 deletions(-)

Comments

Jun Nie Aug. 6, 2022, 4:43 a.m. UTC | #1 
Stephan Gerhold <stephan@gerhold.net> 于2022年8月5日周五 17:32写道：
>
> On Fri, Aug 05, 2022 at 03:49:31PM +0800, Jun Nie wrote:
> > Support dynamic voltage frequency scaling inside clock controller with
> > changes in clock framework. And added msm8916 as the first SoC to
> > support this feature.
> >
>
> As far as I understand it was decided to handle this on the consumer
> driver side in mainline, together with OPP tables and "required-opps" in
> the device tree. If you look at e.g. sc7180.dtsi you can see that this
> is heavily used there. Also see e.g. [1] for some links to related
> discussions.
>
> For MSM8916 at least the SDHCI and DSI driver should support this
> already. Some other older drivers (e.g. QUP, USB) would need some change
> similar to [2] (just like they still need changes for interconnects).
>
> I'm not entirely sure why it was decided to not do this as part of the
> clock core (maybe someone can explain or link a relevant mailing list
> post?), but we should try to keep it consistent in any case. :)
>
> Thanks,
> Stephan

Hi Stephan,
Thanks for the reminder! My work in clk framework was done 2 years ago actually.
I guess it is just before the decision to use consumer side opps for
this, because
I did not see any solution at the time.

I think the consumer side required-opps is better than my solution.
Because clock
is infrastructure to initialize other devices in most cases. If clock
device depends
on power domains, we have to initialize the power domain first. So adjustment in
initialization sequence of many devices is needed sometimes. The consumer side
operation avoid such inconvenience.

So let's forget this patch set.

Regards,
Jun

>
> [1]: https://lore.kernel.org/linux-arm-msm/20200910162610.GA7008@gerhold.net/
> [2]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0472f8d3c054a0ff58122fc9d2dbf84f197a284f