Thomas Petazzoni had written, on 09/02/2010 02:43 AM, the following:
Hello,
On Wed, 01 Sep 2010 15:51:40 -0700
Kevin Hilman <khilman@xxxxxxxxxxxxxxxxxxx> wrote:
Looking closer at this, keeping track of a list of devices and
constraints is what the regulator framework does as well.
Before we get too far down this path, we need to start working with
Thomas Petazzoni to better understand how we can use the regulator
framework for much of the management levels of the voltage layer.
Yes, as discussed on IRC with Kevin, I think that some of this voltage
layer mechanisms would benefit from using the existing kernel regulator
framework.
The regulator framework already keeps tracks of consumers (in your
patch set called "vdd users"), and for each consumer, keeps track of
the requested voltage. The maximum requested voltage is then applied to
the regulator. It seems to fit quite well some of the mechanisms you're
introducing in this patch set.
Just brainstorming -> if we use the regulator framework - there are
potential benefits - agreed. BUT, consider the cpuidle path -> currently
we disable SR while hitting off/ret for class3, this is done in irq
locked context while the regulator framework uses locks by itself - we
would probably have to evolve an entirely different mechanism to handle
this.
SR by itself can easily be represented I believe and my thoughts when i
initialy looked at that option had been:
a) latency overheads
b) flexibility we achieve vs complexity in s/w implementation
c) lock handling - esp impact on omap_sram_idle paths..
--
Regards,
Nishanth Menon
PS:personally though concept of latency additions when scaling voltages,
disabling SR etc should be a parameter in userspace governor decisions
(the fact that cpuidle and cpufreq are independent statemachine is not
my personal fav either). But this is a larger topic of discussion not
pertinent to this thread..
--
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
