Message ID | 20220805074935.1158098-1-jun.nie@linaro.org (mailing list archive) |
---|---|
Headers | show |
Series | Support dynamic voltage frequency scaling inside clock controller | expand |
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 [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
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