OMAP3+ updates

checkt: show cpu stats per cpu core
ramdisk: immediate suspend to ram

(still needs to be tested)
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>
OMAP3630+: SmartReflex : 1p5: add qos request

Since we do calibration sequences out of the DVFS path, we still
need to honor the requirement not to interrupt the hardware activities
by attempting lower power states untill calibration is complete.
Hence request a QoS while we have hardware calibration sequence
active and monitoring is in progress.

We currently have check for work->active and abort as part of trigger
sequence from 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!!!
  we then 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 these to take place while we are capturing a calibrated
voltage for the OPP.

Change-Id: I217d80b1ffcf7cbe80eea4ceb29363bd2d25178e
Reported-by: Shashi Shekar B.S. <shashi.shekar@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.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+: 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+: 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>
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+: 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>
OMAP3+: Smartreflex: fix interrupt status clear write

ChangeId Ic0e3d9960ed9511769c3c25b2c71ff1e53bcc796
(OMAP3+: Smartreflex: Fix interrupt disable sequence)
intended to write the interrupt mask to status register
prior to disabling it, instead, we ended up writing 0
to the register, essentially leaving the interrupt status
not cleared. Fix this by splitting the interrupt disable
sequence out(v1 and v2 require different operation) and
ensure we write the correct value to interrupt status register.

Change-Id: Ib28352ff9ea4ec4b787aeee14a907e73080a6d12
Signed-off-by: Nishanth Menon <nm@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>