SIO and OMAP2PLUS changes
Details and cleanup for 1.35ghz overclock
OMAP4: Workaround the OCP synchronisation issue with 32K synctimer.

Backport from:
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap.git;
a=commitdiff;h=68523f4233de5f233478dde0a63047b4efb710b8

Original comment:
On OMAP4, recently a synchronisation bug is discovered by hardware
team, which leads to incorrect timer value read from 32K sync timer
IP when the IP is comming out of idle.

The issue is due to the synchronization methodology used in the SYNCTIMER IP.
The value of the counter register in 32kHz domain is synchronized to the OCP
domain register only at count up event, and if the OCP clock is switched off,
the OCP register gets out of synch until the first count up event after the
clock is switched back -at the next falling edge of the 32kHz clock.

Further investigation revealed that it applies to gptimer1 and watchdog timer2
as well which may run on 32KHz. This patch fixes the issue for all the
applicable modules.

The BUG has not made it yet to the OMAP errata list and it is applicable to
OMAP1/2/3/4/5. OMAP1/2/3 it is taken care indirectly by autodeps.

By enabling static depedency of wakeup clockdomain with MPU, as soon as MPU
is woken up from lowpower state(idle) or whenever MPU is active, PRCM forces
the OCP clock to be running and allow the counter value to be updated properly
in the OCP clock domain.

The bug is going to fixed in future OMAP versions.

Change-Id: I3c7ff239c3dcac180fcae50c1b909d417b2b8e16
Reported-Tested-by: dave.long@linaro.org
[dave.long@linaro.org: Reported the oprofile time stamp issue with synctimer
and helped to test this patch]
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Andrii Tseglytskyi <andrii.tseglytskyi@ti.com>
net: check return value for dst_alloc

return value of dst_alloc must be checked before use

Signed-off-by: Madalin Bucur <madalin.bucur@freescale.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
ipv6: check return value for dst_alloc

return value of dst_alloc must be checked before use

Signed-off-by: Madalin Bucur <madalin.bucur@freescale.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
cpufreq: interactive: restart above_hispeed_delay at each hispeed load

Change-Id: I2e5b91d45e8806b0ab94ca2301ed671c9af9ab13
Signed-off-by: Todd Poynor <toddpoynor@google.com>

Conflicts:

	drivers/cpufreq/cpufreq_interactive.c
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>
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: Add ARM cpu topology definition

The affinity between ARM processors is defined in the MPIDR register.
We can identify which processors are in the same cluster,
and which ones have performance interdependency. We can define the
cpu topology of ARM platform, that is then used by sched_mc and sched_smt.

The default state of sched_mc and sched_smt config is disable.
When enabled, the behavior of the scheduler can be modified with
sched_mc_power_savings and sched_smt_power_savings sysfs interfaces.

Changes since v3 :
* Update the format of printk message
* Remove blank line

Changes since v2 :
* Update the commit message and some comments

Changes since v1 :
* Update the commit message
* Add read_cpuid_mpidr in arch/arm/include/asm/cputype.h
* Modify header of arch/arm/kernel/topology.c
* Modify tests and manipulation of MPIDR's bitfields
* Modify the place and dependancy of the config
* Modify Noop functions

Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
Reviewed-by: Amit Kucheria <amit.kucheria@linaro.org>
Signed-off-by: vork <boss.benedikt@googlemail.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>

Conflicts:

	include/trace/events/cpufreq_interactive.h
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>
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>
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>