diff options
author | Nishanth Menon <nm@ti.com> | 2011-02-13 21:27:30 +0530 |
---|---|---|
committer | Todd Poynor <toddpoynor@google.com> | 2011-11-30 15:26:41 -0800 |
commit | d3388088b3e0e96df70bc726ce875085b801cf8c (patch) | |
tree | 04408fedc1db0697326f9227b09ba53447689bbd /arch/arm/mach-omap2/vp.h | |
parent | 190f287f035885b34ff08b7e4c88d6c9c32d06d6 (diff) | |
download | kernel_samsung_tuna-d3388088b3e0e96df70bc726ce875085b801cf8c.zip kernel_samsung_tuna-d3388088b3e0e96df70bc726ce875085b801cf8c.tar.gz kernel_samsung_tuna-d3388088b3e0e96df70bc726ce875085b801cf8c.tar.bz2 |
OMAP3+: voltage: use volt_data pointer instead values
Voltage values can get confusing in meaning with various SmartReflex
classes being active. Depending on the class used, the actual voltage
selected might be a variant. For example:
With SmartReflex AVS class 3:
a) If we don't have SR enabled, we will go to volt_nominal.
b) If have SR enabled, we go to volt_nominal, then enable SR and
expect it to adjust voltage. We don't really care about the
resultant voltage.
Essentially, when we ask voltage layer to scale to voltage x for OPP
y, it always means x is the nominal voltage for OPP y.
Now, once we introduce SmartReflex AVS class 1.5:
a) If you are booting for the first time OR if you never enabled SR
before, we always go to volt_nominal.
b) If you enable SR and the OPP is calibrated, we will not enable SR
again when that OPP is accessed anymore, but when we set voltage for
an OPP, the voltage achieved will be volt_calibrated.
c) If recalibration timeout triggers or SR is disabled after a
calibration, the calibrated values are not valid anymore, at this point,
setting the voltage will mean volt_dynamic_nominal.
So, depending on which state the system is at, voltage for that OPP
we are setting has not 1 single value anymore, but 3 possible valid
values.
For upper layers(DVFS/cpufreq OMAP SoC layers) to use voltage values, it
will need to know which type of voltage AVS strategy is being used and
the corresponding system state from voltage layer perspective. This
would replicate the role of voltage layer, SmartReflex AVS in the upper
layers and make the corresponding implementations complex.
Since each voltage domain contains a set of volt_data structs representing
a voltage point that is supported for that domain, volt_data is a more
accurate representation of the voltage point we are interested in going to,
and the actual translation of this voltage point to the voltage value is
done inside the voltage layer. Doing this allows the users of the voltage
layer to be blissfully ignorant of any complexity of the underneath
layers and simplify the implementation of dependent layers.
As part of this change, omap_voltage_get_nom_volt has been renamed to
omap_voltage_get_curr_vdata to better represent it's behavior.
Change-Id: Idc171b6c64224c017280e0b29eb4ffb54f702194
Signed-off-by: Nishanth Menon <nm@ti.com>
Diffstat (limited to 'arch/arm/mach-omap2/vp.h')
-rw-r--r-- | arch/arm/mach-omap2/vp.h | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/arch/arm/mach-omap2/vp.h b/arch/arm/mach-omap2/vp.h index e5f65fd..c3a1e69 100644 --- a/arch/arm/mach-omap2/vp.h +++ b/arch/arm/mach-omap2/vp.h @@ -114,7 +114,7 @@ void omap_vp_enable(struct voltagedomain *voltdm); void omap_vp_disable(struct voltagedomain *voltdm); unsigned long omap_vp_get_curr_volt(struct voltagedomain *voltdm); int omap_vp_forceupdate_scale(struct voltagedomain *voltdm, - unsigned long target_volt); + struct omap_volt_data *target_v); int omap_vp_update_errorgain(struct voltagedomain *voltdm, unsigned long target_volt); |