On Thu, Dec 11, 2014 at 07:31:43PM -0800, Doug Anderson wrote: > On Thu, Dec 11, 2014 at 4:24 PM, Mark Brown <broonie at kernel.org> wrote: > > I mean the latter - what happens if more than one consumer is trying to > > use the regulator? This is IIRC why _set_voltage_tol() uses the cheap > > and nasty implementation it does. > Ah, I see. I don't think I've ever encountered a case where there > were two consumers for a regulator that actually requested voltages... > ...but isn't regulator_set_voltage_tol() broken there? If you have > two clients, A and B and a regulator that can go 1.0V to 5.0V in .05V > increments: > A requests 1.8V +/- .1V. We get 1.8V > B requests 1.7V +/- .05V. > The above could be achievable with a voltage of 1.75V but it won't > work with the current regulator_set_voltage_tol() I think. Yeah, it's not perfect but it'll work most of the time. > > 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. 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? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-rockchip/attachments/20141212/c79e5710/attachment.sig>
