On Wed, Mar 2, 2016 at 5:24 AM, Mark Brown broonie@kernel.org wrote:
On Wed, Mar 02, 2016 at 03:58:31PM +0530, Viresh Kumar wrote:
On 02-03-16, 11:50, Mark Brown wrote:
I'm really not sure what I can say here that I've not already said repeatedly, what's new here?
Yeah, you have raised some genuine concerns earlier, like the sequence in which the voltages of multiple supplies should be changed, and if we should rely on some DT sequence for that.
I started it again, because we have a real case now (not like the virtual case earlier) where a platform has multiple supplies for a device (CPU). I just wanted to hear from all of you on how should we go ahead and solve it.
TI guys had some crazy ideas, like using OPP-notifiers to update the second regulator, etc and I really hated it :)
Ummm... We prefer not to do this via notifier solution.. yeah doing that around notifiers is indeed a crazier alternative
My main thought with this stuff is that if it's really complicated to write generic code that might be a sign that it's sensible to write a custom driver. We can always writee something later if we figure out some general patterns.
We did propose to go via voltage domain[1] to actually do an OPP transition and provide hooks that can implement required regulator set for the SoC. After seeing dev_pm_opp_set_rate is available, it does not make sense to go down the voltagedomain path anymore.
We do have a real need to control multiple regulators around an OPP change. this logic is valid for more than CPU device -> it is valid for devices like DSP, GPU etc in the SoC as well across multiple families in the OMAP generation SoCs. The logic by itself it not too complicated. a voltage plane for a device has two regulators that need to be controlled in tandem for a given target frequency. by allowing dev_pm_opp_set_rate to control "n" regulators it actually does simplify the problem down for a generic solution -> DVFS for devices triggered from cpufreq or via devfreq.
[1] http://marc.info/?l=linux-omap&m=139275579731801&w=2
--- Regards, Nishanth Menon