Message ID | 1348073905.11116.80.camel@hornet (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
On Wed, Sep 19, 2012 at 05:58:25PM +0100, Pawel Moll wrote: > On Wed, 2012-09-19 at 03:21 +0100, Mark Brown wrote: > > No, we should provide a way to describe this situation in the API - it's > > not unreasonable and having to pick step sizes is obviously suboptimal. > Actually before I finally got this mail (our mail system was playing > stupid today), I came up with idea of using the power supply specified > tolerance as a base to chose the step sizes. This comes down to such > code (with the regulator_*_voltage_linear in the ops): That's probably OK, though check that the numbers come out sensible (people tend to work to nice round numbers). > + if (ret < 0) { > + /* No operating points defined, allow any value within range */ > + struct regulation_constraints *constraints = > + regulator->rdev->constraints; > + > + return min_uV >= constraints->min_uV && > + max_uV <= constraints->max_uV; > + } I'd rather have the driver explicitly say it supports continuous voltages with a flag in the descriptor (to make sure we don't end up being overly optimistic because the driver wasn't well implemented) but other than that this looks good.
On Thu, 2012-09-20 at 14:01 +0100, Mark Brown wrote: > > Actually before I finally got this mail (our mail system was playing > > stupid today), I came up with idea of using the power supply specified > > tolerance as a base to chose the step sizes. This comes down to such > > code (with the regulator_*_voltage_linear in the ops): > > That's probably OK, though check that the numbers come out sensible > (people tend to work to nice round numbers). These calculations try to maximize the range, but in most cases it's impossible to be exactly in line with constraints. The delta should be less then 1%, eg. in my test case I get: A15 Vcore: override max_uV, 1050000 -> 1049990 A15 Vcore: 800 <--> 1049 mV at 906 mV I could try to add more math to interpolate the operating points to get perfect match, but this sounds like a serious overkill... > > + if (ret < 0) { > > + /* No operating points defined, allow any value within range */ > > + struct regulation_constraints *constraints = > > + regulator->rdev->constraints; > > + > > + return min_uV >= constraints->min_uV && > > + max_uV <= constraints->max_uV; > > + } > > I'd rather have the driver explicitly say it supports continuous > voltages with a flag in the descriptor (to make sure we don't end up > being overly optimistic because the driver wasn't well implemented) Ok, so I see two options: 1. Something like bool "regulator_desc.linear" 2. A magic value for regulator_desc.n_voltages, something like #define N_VOLTAGES_LINEAR (~0) Does any of them seem reasonable? Pawel
On Thu, Sep 20, 2012 at 06:34:32PM +0100, Pawel Moll wrote: > These calculations try to maximize the range, but in most cases it's > impossible to be exactly in line with constraints. The delta should be > less then 1%, eg. in my test case I get: No, what I mean is that we don't want steps of 343uV or something. > 1. Something like bool "regulator_desc.linear" > 2. A magic value for regulator_desc.n_voltages, something like > #define N_VOLTAGES_LINEAR (~0) > Does any of them seem reasonable? The former of them seems much more tasteful, though I'd go with continuous_volt or something, we already have linear maps.
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index 4838531..a091719 100644 --- a/drivers/regulator/core.c +++ b/drivers/regulator/core.c @@ -1948,8 +1948,14 @@ int regulator_is_supported_voltage(struct regulator *regulator, } ret = regulator_count_voltages(regulator); - if (ret < 0) - return ret; + if (ret < 0) { + /* No operating points defined, allow any value within range */ + struct regulation_constraints *constraints = + regulator->rdev->constraints; + + return min_uV >= constraints->min_uV && + max_uV <= constraints->max_uV; + } voltages = ret; for (i = 0; i < voltages; i++) {