Thanks for this Dave :) On 15-11-16, 16:10, Dave Gerlach wrote: > NOT FOR MERGE! > > Introduce a test version of a 'ti-opp-domain' driver that will use new > multiple regulator support introduced to the OPP core by Viresh [1]. > Tested on v4.9-rc1 with that series applied. This is needed on TI > platforms like DRA7/AM57 in order to control both CPU regulator and > Adaptive Body Bias (ABB) regulator as described by Nishanth Menon here > [2]. These regulators must be scaled in sequence during an OPP > transition depending on whether or not the frequency is being scaled up > or down. Based on the new functionality provided by Viresh this driver > does the following: > > * Call dev_pm_opp_set_regulators with the names of the two regulators > that feed the CPU: > * vdd is the 'cpu-supply' commonly used for cpufreq-dt but > renamed so the cpufreq-dt driver doesn't use it directly. > Note that this is supplied in board dts as it's external to > SoC.
I think I can fix this somehow.. Lemme check. > * vbb for the ABB regulator. This is provided in SoC dtsi as it > is internal to the SoC. > * Provide a platform set_opp function using > dev_pm_opp_register_set_opp_helper that is called when an OPP > transition is requested. > * Allow cpufreq-dt to probe which will work because no cpu-supply > regulator is found so the driver proceeds and calls > dev_pm_opp_set_rate which through the OPP core invokes the platform > set_opp call we provided > * Platform set_opp call provided by this driver checks to see if we are > scaling frequency up or down and based on this, scales vbb before vdd > for up or the other way around for down. > > In addition to that, this driver implements AVS Class 0 as described in > section 18.4.6.12 of AM572x TRM [3] using the same platform set_rate > hook added to the OPP core. There are registers that define the optimal > voltage for that specific piece of silicon for an OPP so this driver > simply looks up this optimal value and programs that for an OPP instead > of the nominal value. > > Missing from this is a good way to ensure that cpufreq-dt does not just > proceed if no cpu-supply regulator is found but we were intending to > rely on a platform set_opp and multiple regulators. > > [1] https://marc.info/?l=linux-pm&m=147746362402994&w=2 > [2] https://marc.info/?l=linux-pm&m=145684495832764&w=2 > [3] http://www.ti.com/lit/ug/spruhz6g/spruhz6g.pdf > > Signed-off-by: Dave Gerlach <d-gerl...@ti.com> > --- > arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi | 2 +- > arch/arm/boot/dts/dra7.dtsi | 46 ++- > drivers/soc/ti/Makefile | 2 + > drivers/soc/ti/ti-opp-domain.c | 427 > ++++++++++++++++++++++++ I would rather ask you to move this to drivers/base/power/opp/ -- viresh
