Mark, On Fri, Dec 12, 2014 at 4:59 AM, Mark Brown <broonie at kernel.org> wrote: >> > There's also the potential >> > performance considerations for the DVS type applications now I think >> > about it. > >> Iterating through voltages is really that slow? If so, perhaps we >> could add some caching to keep track of what voltage we actually got >> last time... I could also add an optimization to try the exact >> requested voltage right away... > > Applications like DVS get pretty performance sensitive and for a > regulator with high resolution if you're trying to hit a voltage at the > top of the range you could be iterating over a hundred or more values. OK, you've convinced me. :) > Perhaps doing something based on the various factorings out of the > voltage mapping would do the trick, add a new op for getting to the > closest voltage? I'd really rather add a new op because I think it would mean that all the old regulators that don't implement the op would be slow all of a sudden. :( I looked at trying to refactor everything, but I think the answer is that I should drop my patch and consider the existing regulator_set_voltage_tol() experience good enough. While I could go through and try to make regulator_set_voltage_tol() better: 1. It fixes no issues that I know of. On all boards that I've worked with it is possible to make VMMC and VQMMC exactly equal. 2. As you said, regulator_set_voltage_tol() is on the critical path for CPUfreq and the existing code is heavily optimized to work fast on a large number of different types of regulators. Trying to replicate that without huge code duplication and without any bugs would be difficult. I'll spin my MMC patch to use regulator_set_voltage_tol(). If Ulf responds and says that he'd like to more accurately specify the min/max voltage then I'll post up a new function using a scheme like regulator_set_voltage_tol() but asymmetric. As always, thanks for your great feedback! -Doug
