On Fri, Mar 20, 2015 at 11:55:50AM +0100, Ulf Hansson wrote: > On 19 March 2015 at 12:36, Mark Brown <broonie@xxxxxxxxxx> wrote: > > The implementation *should* do that anyway, it's just not trivial to > > implement in an efficient fashion with the current information we have > > from drivers. > The APIs regulator_count_voltages() and regulator_list_voltage(), are > currently used from the mmc core to find out which voltages that is > supported (with 0.1V granularity). Then that information can be used > when trying to set a new voltage. > But I guess such a wrapper API is out of the question? > Anyway, I get the feeling that we will need to do the same for this case. As previously discussed the problem is that there can be a *lot* of voltages on a modern regulator with fine grained voltage steps and tolerances are also used for things like cpufreq where we care about performance. We need something that doesn't require a linear scan of possible values. > >> would be good to allow both upper and lower limits to be zero. > > The lower limit can be zero already though it isn't clear to me that > > this is useful. Setting an upper limit of zero seems nonsensical, an > > upper limit that is lower than the lower limit isn't terribly obvious > > and removing the upper limit isn't safe - it means that we'll happily > > oversupply things which is a road to physical damage. > I am not sure I follow here. In the regulator_set_voltage_tol() you > can only specifiy one limit (tolerance?). What Dough proposed was to > add a new API which can have both a low tolerance value and a high > tolerance value. Tolerances are not limits - when you say "limit" that sounds like a hard value. I can't see any reason why the code would prevent anyone setting a tolerance of zero, though it should be rare that this is actually the best thing to do.
Attachment:
signature.asc
Description: Digital signature
