cpufreq: interactive: Boost frequency on touchscreen input

Based on previous patches by Tero Kristo <tero.kristo@nokia.com>,
Brian Steuer <bsteuer@codeaurora.org>,
David Ng <dave@codeaurora.org>,
Antti P Miettinen <amiettinen@nvidia.com>, and
Thomas Renninger <trenn@suse.de>

Change-Id: Ic55fedcf6f9310f43a7022fb88e23b0392122769
Signed-off-by: Todd Poynor <toddpoynor@google.com>
cpufreq: interactive: remove unused target_validate_time_in_idle

Change-Id: I37c5085b91318242612440dfd775ad762996612f
Signed-off-by: Todd Poynor <toddpoynor@google.com>
cpufreq: interactive: Add sysfs boost interface for hints from userspace

The explicit hint on/off version.

Change-Id: Ibf62b6d45bf6fb8c9c055b9bdaf074ce9374c04f
Signed-off-by: Todd Poynor <toddpoynor@google.com>
cpufreq: interactive: set floor for boosted speed

Allow speed to drop to flooor frequency but not below, don't pin
to speed at last boost.

Change-Id: I0147c2b7a2e61ba16820605af6baaf09570be787
Signed-off-by: Todd Poynor <toddpoynor@google.com>
defconfig: back to interactive as default gov
defconfig: enable synchronisation framework
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>
arm: vfp: Fix memory corruption on PM suspend

Commit 36af2a47 ("ARM: vfp: Always save VFP state in vfp_pm_suspend")
introduced a potential use-after-free bug. On SMP systems,
vfp_current_hw_state might hold dangling pointers in case a task which
used the VFP last migrates to another CPU and then exits. If
vfp_pm_suspend is called while vfp_current_hw_state still holds a
pointer to the freed thread_info, that memory location will be written,
potentially overwriting a new object allocated there.

The original problem is only relevant to UP systems in which the VFP
state is stored lazily.

Fix this by only storing the VFP state on UP systems, and avoid doing so
on SMP ones.

Change-Id: I8f7026eb735b340fcef4cf12fbd12b9a0ea08d3f
Signed-off-by: Ido Yariv <ido@wizery.com>
Signed-off-by: Eyal Shapira <eyal@wizery.com>
Signed-off-by: Colin Cross <ccross@android.com>
ARM: vfp: only clear vfp state for current cpu in vfp_pm_suspend

vfp_pm_suspend runs on each cpu, only clear the hardware state
pointer for the current cpu.  Prevents a possible crash if one
cpu clears the hw state pointer when another cpu has already
checked if it is valid.

Change-Id: I997ab1554944eba86730818ff242d7ebe1b32736
Signed-off-by: Colin Cross <ccross@android.com>
Merge remote-tracking branch 'android-common/android-3.0' into testing

Conflicts:
	Documentation/cpu-freq/governors.txt
Merge commit 'v3.0.30' into android-3.0
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: fixed 80 characters warnings in lowmemorykiller.c

This patch fixes some 80 chatacters limit warnings in the lowmemorykiller.c file

Signed-off-by: Marco Navarra <fromenglish@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
staging: android/lowmemorykiller: Don't grab tasklist_lock

Grabbing tasklist_lock has its disadvantages, i.e. it blocks
process creation and destruction. If there are lots of processes,
blocking doesn't sound as a great idea.

For LMK, it is sufficient to surround tasks list traverse with
rcu_read_{,un}lock().

>From now on using force_sig() is not safe, as it can race with an
already exiting task, so we use send_sig() now. As a downside, it
won't kill PID namespace init processes, but that's not what we
want anyway.

Suggested-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>
Reviewed-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Conflicts:

	drivers/staging/android/lowmemorykiller.c
staging: android/lowmemorykiller: Better mm handling

LMK should not directly check for task->mm. The reason is that the
process' threads may exit or detach its mm via use_mm(), but other
threads may still have a valid mm. To catch this we use
find_lock_task_mm(), which walks up all threads and returns an
appropriate task (with lock held).

Suggested-by: Oleg Nesterov <oleg@redhat.com>
Reviewed-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>
Acked-by: KOSAKI Motohiro <kosaki.motohiro@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
staging: android/lowmemorykiller: No need for task->signal check

task->signal == NULL is not possible, so no need for these checks.

Suggested-by: Oleg Nesterov <oleg@redhat.com>
Reviewed-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>
Acked-by: KOSAKI Motohiro <kosaki.motohiro@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
staging: android/lowmemorykiller: Do not kill kernel threads

LMK should not try killing kernel threads.

Suggested-by: Oleg Nesterov <oleg@redhat.com>
Reviewed-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>
Acked-by: KOSAKI Motohiro <kosaki.motohiro@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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>