Revert "OMAP: omap-mcbsp: Holding min latency constraint"

This reverts commit 24d54453f07d6607cdd7afee13f7b4791fe676e8.
3.2.2exp1
Revert "Revert "OMAP: omap-mcbsp: Holding min latency constraint""

This reverts commit 9180234a725048e1d8d4a5ce6504f739c5213307.
defconfig: changed TCP congestion algorithm from Cubic to Veno

Also enabled vibe control by default
defconfig: disable cpu1 bug workaround to *maybe* reduce reboots
v3.2.2exp2
SR15: Re-introduce SR1.5 to notrim with a workaround
SR15: skip calibration on higher freqs - take two
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>
omap: remoteproc: return -EAGAIN on a suspend time out

Support has been added on the remote processor side to allow
applications to deny the remote processor from going into a
suspend state. If one or more applications on the remote
processor request to avoid suspend, then the suspend flag is
never set by the remote processor while the request is active,
resulting in a timeout on the host side suspend code.

The runtime suspend function for remoteproc returns -EIO at
present in case of a timeout, causing the runtime pm framework
to avoid further runtime pm suspend callbacks. This is not
desired and hence the return value is changed to -EAGAIN. This
allows the runtime pm framework to retry the suspend after the
re-expiration of the timeout. This would allow the applications
on the remote processor to allow or disallow suspend independently
of the host-side.

The inital idea of having -EIO was to avoid callbacks, since a
timeout would mean that the remoteproc is in an error state.
However, if the remoteproc were in a bad state at this point, the
recovery mechanism would kick in and reload the image.

Change-Id: Ic7b9cfa220724e8024b960704598ec93854de86c
Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Miguel Vadillo <vadillo@ti.com>
Signed-off-by: Paul Hunt <hunt@ti.com>
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>
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>