On Mon, Dec 5, 2016 at 3:21 PM, Viresh Kumar <viresh.kumar@xxxxxxxxxx> wrote: > On 1 December 2016 at 16:28, Viresh Kumar <viresh.kumar@xxxxxxxxxx> wrote: >> Hi, >> >> Some platforms (like TI) have complex DVFS configuration for CPU >> devices, where multiple regulators are required to be configured to >> change DVFS state of the device. This was explained well by Nishanth >> earlier [1]. >> >> One of the major complaints around multiple regulators case was that the >> DT isn't responsible in any way to represent the order in which multiple >> supplies need to be programmed, before or after a frequency change. It >> was considered in this patch and such information is left for the >> platform specific OPP driver now, which can register its own >> opp_set_rate() callback with the OPP core and the OPP core will then >> call it during DVFS. >> >> The patches are tested on Exynos5250 (Dual A15). I have hacked around DT >> and code to pass values for multiple regulators and verified that they >> are all properly read by the kernel (using debugfs interface). >> >> Dave Gerlach has already tested [2] it on the real TI platforms and it >> works well for him. >> >> This is rebased over: linux-next branch in the PM tree. >> >> V6->V7: >> - Added RBY from Stephen for the 8th patch as well. >> - Rebased over pm/bleeding-edge as the dependency patch is already >> applied there. >> - s/dev_pm_opp_set_regulator()/dev_pm_opp_set_regulators() in a comment. >> - Removed the local 'names' array in cpufreq-dt and used "&name" >> instead. >> - Only the 6th patch doesn't have a Reviewed-by Tag now.. > > Hi Rafael, > > V6 of this series received some minor comments [1] and I have > resolved them all here. Now that the merge window is so close, > I think we should be merge it now so that it gets a chance to live > in linux-next for few days. I've queued them up, but I'd feel more comfortable with an ACK or Reviewed-by on patch [6/10] too. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
