OMAP3+: Smartreflex: Fix interrupt disable sequence

With the current interrupt disable sequence, we disable IRQENABLE
followed by clearing of IRQSTATUS. With this sequence, we see, at
times CORE domain does not hit OFF mode during cold boot because
SR modules(Core/IVA/MPU domains) are stuck 'in transition'.

After the IRQ is cleared by writing the SR_xxx_IRQENABLE_CLR ,
the SW cannot read the interrupt status from IRQSTATUS register.
SW should have cleared all IRQ completely before disabling the
module. If the SW disable the module by the MODULEMODE bit
before clearing the IRQ status, the SR module is still in the
'In transition' mode.

Hence, the right sequence we have is write to IRQSTATUS register
to clear the interrupt, then write to IRQENABLE_CLR register to
disable the interrupt to ensure that no pending interrupts exist
in the system on disable of SmartReflex AVS block.

Change-Id: Ic0e3d9960ed9511769c3c25b2c71ff1e53bcc796
Reported-by: Honda Kenji <x0092217@ti.com>
Reported-by: Maki Tanaka <m-tanaka1@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Huzefa Kankroliwala <huzefank@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>
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>
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>
Staging: android: timed_gpio: Fix resource leak in timed_gpio_probe error paths

If gpio_request fails, we need to free all allocated resources.
Current code uses wrong array index to access gpio_data array.
So current code actually frees gpio_data[i].gpio by j times.

This patch moves the error handling code to err_out and thus improves
readability.

Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Variable GPU OC: sysfs interface to cycle through different top gpu speeds

- /sys/devices/system/cpu/cpu0/cpufreq/gpu_oc
- for now: 0 = 307mhz, 1 = 384mhz, 2 = 512mhz
- changes take effect immediately of course.

Conflicts:

	arch/arm/mach-omap2/omap2plus-cpufreq.c
	arch/arm/mach-omap2/opp4xxx_data.c