Messages in this thread | | | Date | Fri, 11 Mar 2011 15:20:37 +0000 | From | Mark Brown <> | Subject | Re: [PATCH 1/4] regulator: add set_voltage_time[_sel] infrastructure |
| |
On Fri, Mar 11, 2011 at 03:45:39PM +0100, Linus Walleij wrote: > On Fri, Mar 11, 2011 at 1:25 PM, Mark Brown
> + /* > + * If we can't obtain the old selector there is not enough > + * info to call set_voltage_time_sel(). > + */ > + if (rdev->desc->ops->set_voltage_time_sel && > + rdev->desc->ops->get_voltage_sel) { > + unsigned int old_selector = 0; > + > + ret = rdev->desc->ops->get_voltage_sel(rdev); > + if (ret < 0) > + return ret; > + old_selector = ret; > + delay = rdev->desc->ops->set_voltage_time_sel(rdev, > + old_selector, selector); > + } > +
Hrm, right. This means we can only support this for selector based get_voltage(). That's probably fine, I think.
> > I also think we should be exporting this to consumers as things like > > cpufreq are interested in the latency for voltage changes.
> Can we take that when we have a consumer that wants it? Looking > at it it becomes rather complex, since consumers don't know the > core-internal selectors, just discrete enumerated voltages, so these > have to be mapped back to selectors etc, that's pretty much ovehead > code that sits unused.
> (If you insist, I will implement it.)
Consumers know about the set of selectors as they are used to enumerate the supported voltages via list_voltage(). An existing cpufreq driver such as the s3c64xx one would be able to take advantage of this very quickly.
| |