pm: cpufreq: boost cpu frequency API support

This patch introduces boost sysfs interface which would enable the
govenor to ack any request for running the system at max freq just before
the system is going to be loaded. The next sample time would be decided
based on the user configured timeout value or the default (0) usec.

To set boost timeout:
echo <in usec> > /sys/devices/system/cpu/cpufreq/interactive/boost_timeout

To enable boost:
echo 1 > /sys/devices/system/cpu/cpu0/cpufreq/boost_cpufreq

Change-Id: I06840c1b27ecef326f48c24d37be452fdf65a001
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
cpufreq: interactive governor: Delete boost timer on CPUFREQ_GOV_STOP.

Concurrent execution of CPUFREQ_GOV_STOP and interactive_boost_timer()
should be avoided.
Also, interactive_boost() should follow CPUFREQ_GOV_STOP on
flush_work().

Change-Id: I53e897d5ee1834f5cbf0778dd48fc604ec3ea34d
Signed-off-by: Oleg Matcovschi <oleg.matcovschi@ti.com>
PM: OPP: Add opp_find_volt_floor/ceil functions

Add functions to find OPP by voltage value
in the same way as it is made for frequency.

Change-Id: Ic7250258de82ca02d4ee27cfa53bafc7de87685f
Signed-off-by: Taras Kondratiuk <taras@ti.com>
OMAP3+: PM: DVFS: Scale dependent domains to existing OPP

Currently dependent domain is scaled to:
 - dependent voltage that is got from voltage dependency table.
 - frequency that is got from OPP found for dependent voltage.

OPP for dependent voltage is found by _volt_to_opp() function
which looks for OPP with equal or _greater_ voltage.
So if there is no OPP with exact voltage (or this OPP is disabled),
then frequency from OPP with higher voltage will be used.

As a result device will run at not supported combination of frequency and voltage.
This may lead to instabilities.

This patch scales dependent domain to a correct voltage-frequency tuple,
by using both frequency and voltage from the matched OPP.

Change-Id: Ieb14be32ce2f6f2971ca0530dd077bb445a7e2f7
Signed-off-by: Taras Kondratiuk <taras@ti.com>
OMAP3+: PM: DVFS: add qos requirement to prevent interruptions

DVFS transitions are not meant to be interrupted as the interruptions
can cause severe mismatch in configuration sequences involved in DVFS.

We currently have omap_dvfs_lock check made in omap4_enter_sleep
function, however, considering cpuidle path:
a) omap4_enter_sleep is called by cpuidle's omap4_enter_idle_primary
   after the following steps:
   i) set the log state and set power domain state
   ii) WAIT FOR power domain state to transition!!!
  then we call omap4_enter_sleep
b) Now in omap4_enter_idle_secondary,
  GIC disabled, and we directly hit omap4_enter_lowpwer and goes down

We DONOT want this to take place when DVFS frequency configuration,
voltage programming and smartreflex AVS operations take place.

So request for QoS for the period of transition and release once operation
is done as it is less intrusive and takes care of CPU0 or CPU1 activity
to low power states as well.

Change-Id: I7731a3262bf88dd78e279a8c8306850e077865a5
Reported-by: Vinay Chaurasia <vinaych@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
OMAP3+: PM: DVFS: fix making wrong scale direction decision

In most cases with SmartReflex AVS class 3 and Class 1.5 calibration,
the SR adjusted voltage(Vsr) is usually lower than Vnom, However,
at times, the Vsr for a higher OPP may even be lower than a couple of
lower OPPs. For example, on a specific sample silicon on OMAP4430:
MPU OPP    Vsr                Vnom
OPP50      0.862249970436096  1.025
OPP100     1.03509700298309   1.2
OPPTurbo   1.09257805347443   1.325
OPPNitro   1.18703103065491   1.388
OPPNitroSB 1.29427194595337   1.398

Consider in the above case where we transition from OPPTurbo to OPP100
We are attempting to transition from 1.325V to 1.09V, if we pickup voltage
while SmartReflex AVS convergence is taking place, we might pickup 1.21V
which in effect is a scale down decision flag for DVFS. however,
since SR was active, it could make a jump of upto 8steps (100mV) lowering
the voltage to 1.1V after s/w sampled the voltage, which in reality
should have made SR to do a scale up operation.

This wrong scale direction can result in either dependent domain scale
combination to be performed wrongly OR even scale with lower voltage
for a given transition frequency resulting in device instability.

Fix the same by sampling the voltage only after stopping SmartReflex AVS
convergence.

Change-Id: I119a22b7060f30d123c4fe3bcabfadb6d7d71419
Signed-off-by: Nishanth Menon <nm@ti.com>

Conflicts:

	arch/arm/mach-omap2/dvfs.c
OMAP3+: PM: DVFS: decide to scale dependent domains based on nominal voltage

Current DVFS scale decision assumes voltage dependency - hence the scale
decision is implemented based on voltage transition decision. This is
wrong as the dependency between domains is at OPP tuple level, so
no matter what the voltage level is, if we transition from a lower
frequency to a higher frequency, we should scale dependent domain
ahead of transitioning voltage/frequency for the current domain,
and viceversa when switching to lower OPP.

With Smartreflex AVS Class3 or Smartreflex AVS Class1.5, consider
the following Scenario:
The current OPP might be in
Vnom (Vn) - if SR is disabled OR if SR has not yet made the first
   adjustment
Vcurrent(Vc) - which can either be:
	Vsr_intermdiate(Vi) - if SR was interrupted in the middle
		of convergence
	Vsr(Vs) - if SR has completed adjustment.

For all purposes Current OPP's Vn > Vc.
However, when we consider the new OPP we are entering (assume for
SR1.5, new OPP is not a calibrated opp in this discussion):
Going down, we have the following cases:
Case a) current_Vn > current_Vc > new_Vn
Case b) current_Vn > new_Vn > current_Vc
Going up, we could have:
Case c) new_Vn > current_Vn > current_Vc
OR we might even have a scenario
case d) current_Vn > (current_Vc == new_Vn)

Today's code compares current_Vc against new_Vn, and makes a decision
when to scale dependent domain. This will work find in case (a) and
case (c).

However, in case (b), we scale dependent domain at the wrong time,
in case of case (d), we dont even attempt to scale dependent domains!!

This is wrong. since the comparable factor which closely represents
the order of OPP is Vnom, the right thing to check for scaling dependent
domains is Vnom. Hence use it instead.

Change-Id: I93868743301e115fab8e33ff14317b07b81ef5d8
Signed-off-by: Nishanth Menon <nm@ti.com>
OMAP3+: voltage: omap_voltage_get_voltdata searches only for Vnom

Operational voltage comparisons are wrong in this search since we can
end up with scenarios such as the following:
OPP1 Volt_nominal == OPP2 Volt_calibrated
if the search for Volt_calibrated of OPP2 is done, if OPP1 appears
earlier in the array, this will result in returning the OPP1's
volt_data pointer which is wrong. In such a double match, there is no
real "correct selection" possible.

The current users of this function omap_voltage_get_voltdata are
dvfs.c and pm.c (setting up boot voltage) - both these use Vnom
for search, so it is safe to remove the check for operational voltage
and search for a match only for Vnom.

Change-Id: Ic8455cbd5a00dcc30e4989aa9db9b18c9da9741c
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
OMAP3+: LDO: ensure that right ABB type is selected

since target_volt converted by omap_voltage_get_voltdata to get to
abb type for the OPP voltage level, we can have a scenario as follows:
OPP100 Vnom=1.2V, Vcalib = 0V(not calibrated) ABB type - bypass
OPPNitro Vnom=1.375, Vcalib = 1.2V ABB type = FBB
in this case, voltdm_scale will first gets the operational_voltage
of oppNitro and recieves 1.2V, sends it down to abb_prescale function
which in turn converts it back into vdata using
omap_voltage_get_voltdata
however, omap_voltage_get_voltdata walks through the volt_data array
and finds the first match of OPP100 where Vnom = 1.2V and returns
the volt_data pointer for OPP100, this causes ABB logic to think
that it is attempting to go to an OPP with bypass, which in effect
crashes the device once frequency is set to OPPNitro, but ABB is in
bypass mode.

To solve this, we should pass the exact volt_data pointer down to
the abb prescale and postscale handlers so that this back and forth
conversion error does not take place.

Change-Id: I49099caba069798d7bd8888c614fd5e2e27fab6f
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
OMAP3+: ABB: make the pre and post scale decision based off Vnom

Currently the ABB LDO prescale and post scale configurations are
done based off voltdm_scale. However when Vsr(SR adjusted voltage)
of the current OPP is the same as Vnom(nominal voltage) of the new
OPP, this results in voltdm_scale not being called.

This has a side-effect of prescale and postscale of ABB not being
invoked either. In case where the new OPP requires FBB, this will
result in device failure.

The right procedure is to move the prescale and postscale notifier
out of the voltage scale API, instead have it on top of dvfs path
and depend on nominal voltage scaling direction to give a proper
trigger on need basis.

NOTE: ABB prescale is skipped in pm.c initial configuration to
take care of various types of bad and correct bootloader
configuration.

Change-Id: Ie953f515ab6182d6fa9be85d0ea83228db63d969
Signed-off-by: Nishanth Menon <nm@ti.com>
OMAP3+: DVFS: ensure proper volt config if curr_volt==new_volt

At times when current_volt is same as new voltage, voltdm_scale is not
invoked. Since, vp_err_gain update and voltdm->curr_volt update is done
as part of vc_prescale and post_scale invoked as part of scale call,
these are left configured to old OPP values even if we are moving
to a new OPP.

Update these when we detect voltdm_scale is not being invoked, but
new OPP Vnom is detected.

Change-Id: Ic45d5a51edb4e5fe526529c6040cd014907b560e
Reported-by: Honda Kenji <x0092217@ti.com>
Reported-by: Maki Tanaka <m-tanaka1@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
OMAP3+: DVFS: Use opp_find_volt functions instead of _volt_to_opp

Currently OMAP DVFS framework uses _volt_to_opp() function
to find OPP by voltage, but it is made in a hacky way,
because it doens't have access to list of OPP.

That function has a few important limitations:

1. It assumes that each OPP has an unique frequency value
   so it skips next OPPs with the same frequency.
   For example OMAP4 L3 bus has several OPPs which have
   same frequency, but different voltage values.
   So the function is not able to find correct OPP for L3.

2. Rounding direction is not predictable.
   By default function rounds up, but if requested voltage is
   higher that highest OPP voltage, then function rounds down.
   In most places where the function is used, code expect that
   it rounds down which is opposite to default behavior.

The patch change _volt_to_opp() function by opp_find_volt_ceil()
and opp_find_volt_floor() functions.

Change-Id: Iadc47b662924cd6277a008e8cb0d207ef5eb5598
Signed-off-by: Taras Kondratiuk <taras@ti.com>
OMAP3+: OPP: Remove unused _volt_to_opp() function

_volt_to_opp() is not used in the code anymore so can be removed

Change-Id: I2a9f4303c8ef31df928c0414cd6c3b09cd58e219
Signed-off-by: Taras Kondratiuk <taras@ti.com>
OMAP3+: PM: VP: fix integer truncation error

In the voltage processor, the SPMSUpdateWait is calculated based on the
slew rate and the voltage step (SMPSUpdateWait = slew rate * Voltage Step).
After the voltage processor receives the SMPS_Ack signal, the Voltage
controller will wait for SMPSUpdateWait clock cycles for the voltage to
settle to the new value. For all practical purposes, the waittime
parameter is the hardware translation of what the slew rate on the PMIC
is.

As an example, with TPS62361 on OMAP4460,
step_size = 10000
slew_rate = 32000
sys_clk_rate = 38400

Our current computation of this results in the following:
 = ((step_size / slew_rate) * sys_clk_rate) / 1000
 = ((10000 / 32000) * 38400 / 1000
 = 0

Fix the same using DIV_ROUND_UP as an extra wait clock cycle
is better than lesser clock cycle. For the above example, this
translates to:
 = (10000 * 38400) / (1000 * 32000)
 = 12

Change-Id: I0ee22e60555e1cfd6cc3dea7ee44d0584ce182b6
Acked-by: Jon Hunter <jon-hunter@ti.com>
[nm@ti.com: slightly better implementation]
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Yuan Jiangli <jlyuan@motorola.com>
OMAP3+: PM: VP: dereference voltdm after checking valid voltdm

voltdm should be dereferenced only after voltdm has been checked
for NULL parameters.

Change-Id: I61792933b6a33121dc2e7855e6c0b75f24a0d03b
Reported-by; Hoon Heo <ryan.heo@samsung.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
OMAP3+: VP/VC: ensure vp errgen is configured for the right OPP

Since target_volt converted by omap_voltage_get_voltdata to get to
vp_errgain for the OPP voltage level, we can have a scenario as follows:
OPP100 Vnom=1.2V, Vcalib = 0V(not calibrated) vp_errgain=0x16
OPPNitro Vnom=1.375, Vcalib = 1.2V vp_errgain=0x27
When a request to vc_bypass or vp_forceupdate is provided to OPPNitro
volt_data pointer, it in turn calls vc_prescale with 1.2V, this gets
passed down to vp_errgen_configure, who converts it back into vdata
using omap_voltage_get_voltdata

However, omap_voltage_get_voltdata walks through the volt_data array
and finds the first match of OPP100 where Vnom = 1.2V and returns
the volt_data pointer for OPP100, this causes 0x16 to be selected
for VP errgain instead of 0x27, causing instability for voltage scale
operation.

Instead, pass the volt_data pointer straight to vc_prescale and down
to vp_errgen_configure to ensure that the right configuration parameters
are used.

Change-Id: I96c697175fb5d16c53de9891ec5c008101c0550b
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
pm: cpufreq_interactive: Merge changes from google's kernel/common.git

Taken from TI's Change-Id Ifbd7150801f3beeec9cbaa566f249d8019ef9348

Conflicts:

	drivers/cpufreq/cpufreq_interactive.c
cpufreq: interactiver governor: Add a time view concept

CPUFreq governors are always a tradeoff between power vs performance.
For low power UCs we want to have a less reponsive cpufreq governor that
does not respond or react to each load pick.
However when scrolling on the screen or during webbrowsing we need a more
responsive governor that interact or esponse to each load variation.

To detect which kind of application we have, we'll rely on the history of
the load. if the the average over the load history is high that means we
need to be more responsive so we change the governor paramters in that
direction.
if the average over the load history is low thatmeans we are in low power
UCs so we change the governor parameter to be less responsive

Change-Id: Ifd55ac4cfbc1bd9eded4ae603b158054c6169e8c
Signed-off-by: Nicole Chalhoub <n-chalhoub@ti.com>
Signed-off-by: Taras Kondratiuk <taras@ti.com>
cpufreq: interactive governor: Fix not uniform buf filling & memory corruption

Each CPU has it's own load history buffer, but all they use shared
<history_load_index> variable, this lead to not uniform filling
of the cpu's circular buffers. Only about half of buffer is updated
during each buffer rewriting cycle that obligate governor to use
outdated data during freq tuning.

Moreover access to <history_load_index> variable is not atomic, that
create race conditions. Simultaneous increment could cause situation
where such check:

        if (++history_load_index == sampling_periods)
                history_load_index = 0;

not safe and buffer overflow will not be prevented. That will lead
to memory corruption.

To avoid such problems this patch move buffer-index variable to
<cpufreq_interactive_cpuinfo> structure, which is separate for each CPU.
Also, buffer overflow checking will be paranoidly changed.

Change-Id: I333a4462be17816372a7a57529811d87930058c0
Signed-off-by: Leonid Iziumtsev <x0153368@ti.com>
OMAP3+: SmartReflex: disable errgen before vpbound disable

vpboundsintr_en is available inside the IP block as an re-sycned
version and one which is not. Due to this, there is an 1 sysclk
cycle window where interruptz could be asserted low for 1 cycle.
IF, intr_en is cleared on the exact same cycle as the irqclr, an
additional pulse is generated which indicates for VP that
an additional adjustment of voltage is required.

This results in VP doing two voltage adjustments for the SRERR
(based on configuration, upto 4 steps), instead of the needed
1 adjustment.
Due to the unexpected pulse from AVS which breaks the AVS-VP
communication protocol, VP also ends up in a stuck condition by
entering a state where VP module remains non-responsive
to any futher AVS adjustment events. This creates the symptom
called "TRANXDONE Timeout" scenario.

By disabling errgen prior to disable of intr_en, this situation
can be avoided.

Change-Id: I92012bf49dc83590849c4de8a9cec844cbf66e83
Signed-off-by: Vincent Bour <v-bour@ti.com>
Signed-off-by: Leonardo Affortunati <l-affortunati@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>