On Thu, May 28, 2020 at 01:10:25AM +0200, Niklas Cassel wrote: > On Wed, May 27, 2020 at 10:56:07PM +0200, Stephan Gerhold wrote: > > > If the CPR driver is not changed, which I doubt, you will simply change > > > the device tree to remove the cpu-supply regulator and move it into the > > > new CPR DT node. > > > > > > Old device trees will still use your DVFS solution, new device > > > trees will use the CPR DT node and will use the AVS solution. > > > > > > > I think my concern is essentially that I would duplicate the MEMACC code > > into a new driver utilizing .set_opp() - and to keep backwards > > compatibility we would need to keep that duplication forever. > > The cleanest solution is probably to create a new memacc platform device > driver, and make the new code use that, and refactor CPR to use the same. > I will try to come up with something like that, thank you! > > > > The MEMACC scaling isn't all that complicated, but overall I would > > prefer to avoid introducing duplication in the first place. > > > > Also: If full CPR ever happens we would be basically back > > to one part of the current discussion: specifying two "required-opps" > > MX and CPR (= APC + MEMACC) would result in the wrong order > > when scaling up/down. > > > > But maybe I just worry too much? > > I guess that whoever implements CPR on msm8916 will either call > dev_pm_genpd_set_performance_state() on MX directly from cpr_scale_voltage() > or perhaps change OPP core so that it runs the required-opps in reverse > order when scaling down, like you previously suggested. > > Please don't take my suggestions as the only way forward though. > Hopefully I provided more clarity than confusion. > Will step back so that someone else has a chance to chime in :) I'm a bit confused at the moment, but it's mainly because we discussed so many different options. I will need some time to properly look at all of them and come up with a potential solution. Thanks for taking the time to answer all my questions! :) Stephan
