Add FAST_NO_HZ, update version
Update voltages, correct turbo opp
Update build scripts
Fix dependency for FAST_NO_HZ
OMAP4460: OPP: Move ABB update for MPU OPP turbo to OPP init code

Initially ABB type update was implemented in ABB init code.
This leads to a voltage values duplication.
This patch moves ABB type detection into the OPP init code.

Also disable 500mhz IVA opp
-Drod2169

Change-Id: I6140dff1be0f2b9e667160da957c8e1dbabf3e8f
[taras@ti.com: remove previous implementation]
Signed-off-by: Taras Kondratiuk <taras@ti.com>
[nm@ti.com: movement of code to central opp update]
Signed-off-by: Nishanth Menon <nm@ti.com>
[mturquette@ti.com: original author]
Signed-off-by: Mike Turquette <mturquette@ti.com>

Conflicts:

	arch/arm/mach-omap2/ldo.c
OMAP4460: OPP: update ABB for IVA OPP turbo

On 4460 all OPPs have pre-determined states for VDD_IVA's ABB LDO,
except for OPP_TURBO.  OPP_TURBO may require bypass or RBB.
depending on a characterisation data blown into eFuse
register CONTROL_STD_FUSE_OPP_DPLL_1.

Bit 21 of that register signify DPLL_IVA trim OPP_TURBO might put
IVA's ABB LDO into bypass or RBB based on this value.

This patch introduces ABB type detection into the OPP init code.

Change-Id: Ie2f49652fda667943a7a9ac76d529c6a594b8755
Signed-off-by: Nishanth Menon <nm@ti.com>
OMAP4: OPP: Make ABB type trim update more generic

Change omap4460_abb_update() with generic omap4_abb_trim_update()
So it can be used for other devices and OPPs.

Change-Id: I2390bedc439b3388eda9efbaaecf1d66f7436ab8
Signed-off-by: Taras Kondratiuk <taras@ti.com>
OMAP4: omap_wdt: using of runtime PM is limited

Issues description:

1. On OMAP4 SYSCLK can't be gated, because of issue with WDTIMER2 module,
which constantly stays in "in transition" state. Value of register
CM_WKUP_WDTIMER2_CLKCTRL is always 0x00010000 in this case.
Issue occurs immediately after first idle, when hwmod framework tries
to disable WDTIMER2 functional clock - "wd_timer2_fck". After this
module falls to "in transition" state, and SYSCLK gating is blocked.

2. Due to runtime PM, watchdog timer may be completely disabled.
In current code base watchdog timer is not disabled only because of
issue 1. Otherwise state of WDTIMER2 module will be "Disabled", and there
will be no interrupts from omap_wdt. In other words watchdog will not
work at all.

Solution description:

Using of runtime PM is limited inside omap_wdt driver. Now it
is used only during probe/shutdown and suspend/resume.
As there will be no runtime PM during watchdog timer work, there will be
no attempts of enable/disable functional clock of WDTIMER2.
WDTIMER2 module will change state from "Active" to "Idle",
interrupts from omap_wdt will come normally, there will be no
blockers with SYSCLK.

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

Conflicts:

	drivers/watchdog/omap_wdt.c
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>

Conflicts:

	arch/arm/mach-omap2/pm44xx.c
OMAP4: EMIF: Disable EMIF DDR self refresh during EMIF frequency change sequences

Errata ID: i728

Description:

If during a small window the following three events occur simultaneously:

1) The EMIF_PWR_MGMT_CTRL[7:4] REG_SR_TIM SR_TIMING counter expires
2) Frequency change update is requested CM_SHADOW_FREQ_CONFIG1
   FREQ_UPDATE set to 1
3) OCP access is requested

There will be clock instability on the DDR interface.

Workaround:

Prevent event 1) while event 2) is happening: Disable the self-refresh when
self-refresh is enabled and a frequency change sequence is requested.

Change-Id: I6c216d18f2747dae8a9160669533f0f1582d3301
Signed-off-by: Jacky Cheung <jacky.cheung@ti.com>
omap: remoteproc: return -EAGAIN on a suspend time out
rpmsg: omx: use different name for each rproc in device id_table

The rpmsg omx driver currently uses the same name to match a
device during its probe. The cdevs exposed by the driver are
simply created sequentially in the prone based on the discovery
of each device. The devices can be created in a random order
when multiple remote processors are involved, and is merely a
factor of when the remote processor has come up and published
its OMX service.

Userspace is assuming that the second cdev registered is always
for ipu_c1 (/dev/rpmsg-omx1). This is valid only as long as
ipu is the only remote processor being used. ipu_c1 always gets
created second today due to the boot-up sequence of the ipu
cores and the images they are executing, but this may not be
valid always. When dsp is being used, the rpmsg channel devices
for dsp and ipu can be created in any order. This would break
any existing userspace libraries/applications that may be
communicating with different remote processors.

The device id table is updated now to match specific names to
specific processors, so that they always remain the same
irrespective of the boot sequence.
 "rpmsg-omx0"    ipu_c0
 "rpmsg-omx1"    ipu_c1
 "rpmsg-omx2"    dsp

Change-Id: Ia75f944c87b6dffa982ee208dcaadb48f79da42a
Signed-off-by: Juan Gutierrez <jgutierrez@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
rpmsg: omx: lower the traces level in driver open, ioctl & release

The dev_info traces in open, connect ioctl and release incur a time
penalty and affect application launch time performances. These have
been converted to dev_dbg traces.

Change-Id: Ie8ffd027c4a96bbb5cbfa634f0d661400da8dc09
Signed-off-by: Suman Anna <s-anna@ti.com>