Message ID | 20190320094918.20234-1-rnayak@codeaurora.org (mailing list archive) |
---|---|
Headers | show |
Series | DVFS in the OPP core | expand |
On 20-03-19, 15:19, Rajendra Nayak wrote: > This is a v2 of the RFC posted earlier by Stephen Boyd [1] > > As part of v2 I still follow the same approach of dev_pm_opp_set_rate() > API using clk framework to round the frequency passed and making it > accept 0 as a valid frequency indicating the frequency isn't required > anymore. It just has a few more drivers converted to use this approach > like dsi/dpu and ufs. > ufs demonstrates the case of having to handle multiple power domains, one > of which is scalable. I though we discussed about enabling/disabling clk as well from OPP core to simply driver ? I was expecting that to be part of this version :(
On 20-03-19, 15:19, Rajendra Nayak wrote: > This is a v2 of the RFC posted earlier by Stephen Boyd [1] > > As part of v2 I still follow the same approach of dev_pm_opp_set_rate() > API using clk framework to round the frequency passed and making it > accept 0 as a valid frequency indicating the frequency isn't required > anymore. It just has a few more drivers converted to use this approach > like dsi/dpu and ufs. > ufs demonstrates the case of having to handle multiple power domains, one > of which is scalable. > > The patches are based on 5.1-rc1 and depend on some ufs fixes I posted > earlier [2] and a DT patch to include the rpmpd header [3] > > [1] https://lkml.org/lkml/2019/1/28/2086 > [2] https://lkml.org/lkml/2019/3/8/70 > [3] https://lkml.org/lkml/2019/3/20/120 Hi Rajendra, I am inclined to apply/push this series for 5.3-rc1, will it be possible for you to spend some time on this at priority ?
On 5/21/2019 11:52 AM, Viresh Kumar wrote: > On 20-03-19, 15:19, Rajendra Nayak wrote: >> This is a v2 of the RFC posted earlier by Stephen Boyd [1] >> >> As part of v2 I still follow the same approach of dev_pm_opp_set_rate() >> API using clk framework to round the frequency passed and making it >> accept 0 as a valid frequency indicating the frequency isn't required >> anymore. It just has a few more drivers converted to use this approach >> like dsi/dpu and ufs. >> ufs demonstrates the case of having to handle multiple power domains, one >> of which is scalable. >> >> The patches are based on 5.1-rc1 and depend on some ufs fixes I posted >> earlier [2] and a DT patch to include the rpmpd header [3] >> >> [1] https://lkml.org/lkml/2019/1/28/2086 >> [2] https://lkml.org/lkml/2019/3/8/70 >> [3] https://lkml.org/lkml/2019/3/20/120 > > Hi Rajendra, > > I am inclined to apply/push this series for 5.3-rc1, will it be > possible for you to spend some time on this at priority ? Hey Viresh, I was on vacation, just got back. I will refresh this series and address your previous feedback, I haven't received much feedback for the driver changes :/ but we can atleast review and get the OPP layer changes finalized. thanks.
On 20-03-19, 15:19, Rajendra Nayak wrote: > This is a v2 of the RFC posted earlier by Stephen Boyd [1] > > As part of v2 I still follow the same approach of dev_pm_opp_set_rate() > API using clk framework to round the frequency passed and making it > accept 0 as a valid frequency indicating the frequency isn't required > anymore. It just has a few more drivers converted to use this approach > like dsi/dpu and ufs. > ufs demonstrates the case of having to handle multiple power domains, one > of which is scalable. > > The patches are based on 5.1-rc1 and depend on some ufs fixes I posted > earlier [2] and a DT patch to include the rpmpd header [3] > > [1] https://lkml.org/lkml/2019/1/28/2086 > [2] https://lkml.org/lkml/2019/3/8/70 > [3] https://lkml.org/lkml/2019/3/20/120 > > Rajendra Nayak (10): > OPP: Make dev_pm_opp_set_rate() with freq=0 as valid > > Stephen Boyd (1): > OPP: Don't overwrite rounded clk rate I have applied modified version of these two patches to the OPP tree now. Thanks.