On Mon, Feb 23, 2009 at 12:52:01PM -0800, David Brownell wrote: > Use those methods to force machine-level constraints into bounds. > (Example: regulator supports 1.8V, 2.4V, 2.6V, 3.3V, and board > constraints for that rail are 2.0V to 3.6V ... so the range of > voltages is then 2.4V to 3.3V on this board.) Being able to support this is definitely a win, thanks for looking at this. > + /* maybe force machine-wide voltage constraints to match the > + * voltages supported by this regulator. use the regulator's > + * entire range for boards with no particular constraints. > + */ I'd really rather the second bit weren't here. I'd like to see a warning for the first part. > + * @count_voltages: Return the number of supported voltage indices which > + * may be passed to @list_voltage(). Some indices may correspond to > + * voltages that are not usable on this system. > + * @list_voltage: Return one of the supported voltages, in microvolts; > + * or negative errno. Indices range from zero to one less than > + * @count_voltages(). Voltages may be reported in any order. I'm having a hard time loving this interface for the driver. It feels fairly cumbersome to have to provide two functions to look up what I'd expect to be static data - I'd be fairly surprised to see it change at runtime. I think I'd expect to see something more like the way ALSA represents dB scales where the driver supplies a list of ranges that can either be simple values or value ranges expressed as (start, step, count). That would cover both complicated cases like the TWL4030 and the other common case with large regular ranges of voltages. This mostly applies to the driver interface - on the consumer side it feels a bit cumbersome to use but I can't think of anything that's particularly better. An interface that also allows consumers to ask if particular ranges can be satisfied might help here - it'd be nice for things like MMC that want to check for a relatively small set of voltages or voltage ranges (which I'd expect is the common case). -- 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
