OMAP4: voltage: set VDDMIN to 840000 for stability
cpufreq: interactive: restart above_hispeed_delay at each hispeed load

Change-Id: I2e5b91d45e8806b0ab94ca2301ed671c9af9ab13
Signed-off-by: Todd Poynor <toddpoynor@google.com>
OMAP4: correct CPU Idle settings for exit latency and thresholds

------------------------------------------------------------------------------------
Cstates					exit_latency	thresholds
OMAP4430	CPUs	MPU	Core		us		us	SystemClock
------------------------------------------------------------------------------------
C1		WFI	ON	ON		4		4		ON
------------------------------------------------------------------------------------
C2		OFF	INA	INA		300		300		ON
------------------------------------------------------------------------------------
C3		OFF	CSWR	OSWR		5000		10000		OFF
------------------------------------------------------------------------------------
C4		OFF	OSWR	OSWR		5200		35000		OFF
------------------------------------------------------------------------------------

------------------------------------------------------------------------------------
Cstates					exit_latency	thresholds
OMAP4460	CPUs	MPU	Core		us		us	SystemClock
------------------------------------------------------------------------------------
C1		WFI	ON	ON		4		4		ON
------------------------------------------------------------------------------------
C2		OFF	INA	INA		300		1800		ON
------------------------------------------------------------------------------------
C3		OFF	CSWR	OSWR		4000		4000		OFF
------------------------------------------------------------------------------------
C4		OFF	OSWR	OSWR		4200		4200		OFF
------------------------------------------------------------------------------------

------------------------------------------------------------------------------------
Cstates					exit_latency	thresholds
OMAP4470	CPUs	MPU	Core		us		us	SystemClock
------------------------------------------------------------------------------------
C1		WFI	ON	ON		4		4		ON
------------------------------------------------------------------------------------
C2		OFF	INA	INA		500		1200		ON
------------------------------------------------------------------------------------
C3		OFF	CSWR	OSWR		5300		5300		OFF
------------------------------------------------------------------------------------
C4		OFF	OSWR	OSWR		5500		15000		OFF
------------------------------------------------------------------------------------

Change-Id: I6f9046db4273b10cecd7bf896c1a8488774e0d5b
Signed-off-by: Andrii Tseglytskyi <andrii.tseglytskyi@ti.com>

Patch Set 3
omap2plus: cpufreq: Modify lpj recalculation logic

Somethimes "mdelay" function provide delay
that several times lower than it should be.

This happens because recalculating lpj
performed after switching OPP. In this case,
for short period of time, when OPP on MPU
was switched but lpj was not recalculated,
"udelay" function can provide incorrect
delay - upto 5 times lower
(if OPP was switched from lowest to highest).

This patch changes lpj recalculation logic to:
if OPP will be switched to higher - recalculate lpj before switching OPP,
if OPP will be switched to higher - recalculate lpj after switching OPP.

Change-Id: I3258e756c471fd0258a849d712ab00f4e1279ea9
Signed-off-by: Sergii Postulga <x0153364@ti.com>
Revert "Revert "TUNA: Regulator: Configure VAUX3, VUSIM & VDAC regulators to be disabled in off-mode.""

This reverts commit 9ecf925827b30d73a7136d307d72f2d14ff252e1.
Revert "Revert "TUNA: Regulator: Set initial state of VDAC regulator""

This reverts commit 79806ed7654221384b15890382f3b55d574d1477.
defconfig: update cmplus_tuna

- enabled apm power
OMAP4460: OPP: Add 1500MHz MPU frequency
tuna-wifi: do not randomize MAC if bootloader doesn't pass it

Calculate MAC from SOC die_id which hopefully is unique enough.
OMAP4: PM: cold reset: wrong value is used to set LOGICRETSTATE

OMAP4: PM: cold reset: wrong value is used to set LOGICRETSTATE

The size of LOGICRETSTATE field is 1 bit, and pwrdm_set_logic_retst()
can accept only PWRDM_POWER_RET(0x1)/PWRDM_POWER_OFF(0x0) values.

Additional check of "pwrst" parameter and print out of error message
added in pwrdm_set_logic_retst() to minimize such issues in future.

Change-Id: I413e1e2ba3823574d4450225ed30cffb2cdfd565
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
ARM: cpu topology: Enable ARCH_POWER
mm: ksm: use optimized parameters
cpufreq: interactive: fixup trace of string params

Change-Id: Iac47f62437e61b13724afbbf9df1a0729f58f236
Signed-off-by: Todd Poynor <toddpoynor@google.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>
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+: 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>
OMAP3630+: PM: LDO: ABB: ensure transition complete

Currently when we configure ABB LDO, we do the following:
clear interrupt status
program new ABB
clear interrupt status

This does not guarentee that the ABB LDO has achieved the
desired configuration, and in cases where we are moving to
high performance OPP such as OPP NitroSB, this could result
in undeterministic failures on few corner lots.

Fix to ensure the right sequence as:
clear interrupt status
program new ABB
wait for interrupt
clear interrupt status (even if wait failed.)

Change-Id: Ida9320b9249a134f0ae33adf20ec2be81c806682
Reported-by: Vincent Bour <v-bour@ti.com>
Signed-off-by: Nishanth Menon <nm@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+: 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>
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>