aboutsummaryrefslogtreecommitdiffstats
path: root/arch/arm/mach-omap2/vp.h
diff options
context:
space:
mode:
authorNishanth Menon <nm@ti.com>2011-02-13 21:27:30 +0530
committerTodd Poynor <toddpoynor@google.com>2011-11-30 15:26:41 -0800
commitd3388088b3e0e96df70bc726ce875085b801cf8c (patch)
tree04408fedc1db0697326f9227b09ba53447689bbd /arch/arm/mach-omap2/vp.h
parent190f287f035885b34ff08b7e4c88d6c9c32d06d6 (diff)
downloadkernel_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.h2
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);