Re: [TEST PATCH] WIP: Test OPP multi regulator support with ti-opp-domain driver

[Viresh Kumar <viresh.kumar@linaro.org>]

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-gerlach@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