On Wednesday 25 February 2009, Mark Brown wrote:
> > get_voltage() {
> > read selector from hardware
> > map selector to voltage
> > return that voltage
> > }
>
> > So it's trivial for similar code to take the selector as
> > a function parameter, and do the same thing. Repackage
> > the existing code a bit; bzzt, done!
>
> Yes, that's a reasonable point (though I'd still like to see the maximum
> turn into a static value now I think about it).
At the regulator_desc level, that's trivial; I'll do that
in the patch you'll see.
In terms of the consumer interface, not -- "struct regulator"
is opaque to consumers, and everything is a functional accessor.
So I'll leave that as-is.
> > It will be fairly common for the regulator to support voltages
> > that are disallowed by the machine constraints, though. That
> > can produce "holes" too; and not necessarily only for the lowest
> > or highest selector codes.
>
> At present only continous ranges are possible, though. I can't think of
> any systems I've seen that'd want discontinous constraints, though I'm
> sure there are some.
Consider a regulator where voltage selectors 0..3 correspond to
voltages
{ 3.3V, 1.8V, 4.2V, 5.0V }
With machine constraints that say voltages go from 3V to 4.5V ...
- Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
