lkml.org 
[lkml]   [2011]   [Mar]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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.


\
 
 \ /
  Last update: 2011-03-11 16:23    [W:0.845 / U:0.704 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site