omap: rpmsg: unmap vring memory address

A call to iounmap() of the vring memory address was missing during the deletion
stage of the rpmsg-virtqueues, thus causing a memory leak.

Change-Id: I208c908e064e3c9cc56e6c21736725836eb2d74d

Signed-off-by: Juan Gutierrez <jgutierrez@ti.com>
Signed-off-by: Iliyan Malchev <malchev@google.com>
remoteproc: add mutex protection for traces

In rproc_put() the buffers used to read remoteproc's traces were being unmapped
without any protection.  If at the same time a cat on the traces is done, it
may access an unmapped buffer leading to a crash.

This patch protects the access and unmapping of dump/trace buffers with a
mutex.  It also fixes some checkpatch issues in the trace functions.

Change-Id: I0a6f52e9df691bc1d4ff894febb9a20819b4b7c3

Signed-off-by: Miguel Vadillo <vadillo@ti.com>
Signed-off-by: Iliyan Malchev <malchev@google.com>
OMAP4: PM: fix overconsumption on OFF mode

The wrong value of CM_L3INIT_CLKSTCTRL.CLKTRCTRL = 2 (SW_WKUP)
has been stored in SAR during omap4_sar_save() execution and
causes power over consumption on OFF mode due to C2C operation.
It happens because the L3INIT CD need to be enabled during
omap4_sar_save() execution for proper USBHOST module context storing.

Problematic use case:
1) OMAP goes to sleep,
2) modem wakeup the C2C, the EMIF but the MPU is still sleeping
(as expected)
3) Modem release all his constraints, C2C is turned to OFF.
4) but OMAP never reach again OFF while we don't wakeup the CPU
(by a keypress for example), sys_clk is already ON and voltages
are not equal to 0. (OPP 50 for CORE_3 and retention voltages
for both VCORE1 and VCORE2).

As WA overwrite CM_L3INIT_CLKSTCTRL.CLKTRCTRL = 0x1 (SW_SLEEP).

Change-Id: I2e453c07f61bab28a7213dd66044fd41a021961b
Signed-off-by: Arthur Cassegrain <a-cassegrain@ti.com>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>

Patch Set 1
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.

Change-Id: I413e1e2ba3823574d4450225ed30cffb2cdfd565
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>

Patch Set 2
Revert "OMAPDSS: DSSCOMP: efficiency improvement."

This reverts commit c33f47ec5853b6e522b14c15f29fc03414337aa2.
OMAPDSS: DSSCOMP: efficiency improvement.

This change adds 3 local caches of objects, which are used at each flip buffer
action. In original variant kzalloc()/kfree() functions are called each time
dsscomp_gralloc_queue() function is called. This meens that slab|slob|slub
common cache is used at each frame draw action. Call to kzalloc()/kfree()
result in synchronization with other code, which uses common cache, and can
result in dips in FPS, when other code allocates/frees memory.
This change improves reliability, autonomy and efficiency of DSSCOMP module.

Change-Id: Ibf729b922fcd613ff2a2da8e452e0075f5397e55
Signed-off-by: Mykhailo Denysiuk <x0172934@ti.com>

Patch Set 16
zram: script clean-up
v3.3.0exp4
usb:gadget:android: avoid sending extra uevents

Don't schedule a uevet from android_disconnect
if there is no change in the connection state
and if the DISCONNECT event was already sent.
This patch will avoid these unecessary messages:

android_work: did not send uevent (0 0   (null))

Change-Id: Ic25e09f24098dcc575f4a24fdb0a0ec49ad0f430
Signed-off-by: Moiz Sonasath <m-sonasath@ti.com>
Linux 3.0.30
colorcontrol: fix compiler warning
3.4.0exp1
twl-rtc: mask alarm interrupts at shutdown.

Mask alarm interrupts when the system is shutdown so that we don't
get powered up unnecessarily.

Change-Id: I732577f1d62a28e880c193a3d7d7d6bcdaf863d2
Signed-off-by: Anand Gadiyar <gadiyar@ti.com>
Signed-off-by: Semen Protsenko <semen.protsenko@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>
v3.4.0exp2
colorcontrol for cm9: default is 0 instead of 60 now
tempcontrol: always show current temp in sysfs
ched: Fix select_fallback_rq() vs cpu_active/cpu_online

Commit 5fbd036b55 ("sched: Cleanup cpu_active madness"), which was
supposed to finally sort the cpu_active mess, instead uncovered more.

Since CPU_STARTING is ran before setting the cpu online, there's a
(small) window where the cpu has active,!online.

If during this time there's a wakeup of a task that used to reside on
that cpu select_task_rq() will use select_fallback_rq() to compute an
alternative cpu to run on since we find !online.

select_fallback_rq() however will compute the new cpu against
cpu_active, this means that it can return the same cpu it started out
with, the !online one, since that cpu is in fact marked active.

This results in us trying to scheduling a task on an offline cpu and
triggering a WARN in the IPI code.

The solution proposed by Chuansheng Liu of setting cpu_active in
set_cpu_online() is buggy, firstly not all archs actually use
set_cpu_online(), secondly, not all archs call set_cpu_online() with
IRQs disabled, this means we would introduce either the same race or
the race from fd8a7de17 ("x86: cpu-hotplug: Prevent softirq wakeup on
wrong CPU") -- albeit much narrower.

[ By setting online first and active later we have a window of
  online,!active, fresh and bound kthreads have task_cpu() of 0 and
  since cpu0 isn't in tsk_cpus_allowed() we end up in
  select_fallback_rq() which excludes !active, resulting in a reset
  of ->cpus_allowed and the thread running all over the place. ]

The solution is to re-work select_fallback_rq() to require active
_and_ online. This makes the active,!online case work as expected,
OTOH archs running CPU_STARTING after setting online are now
vulnerable to the issue from fd8a7de17 -- these are alpha and
blackfin.

Change-Id: I34bedb461f77bfe4af78ef5ddd3fb3a230ca3551
Reported-by: Chuansheng Liu <chuansheng.liu@intel.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Mike Frysinger <vapier@gentoo.org>
Cc: linux-alpha@vger.kernel.org
Link: http://lkml.kernel.org/n/tip-hubqk1i10o4dpvlm06gq7v6j@git.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Taras Kondratiuk <taras@ti.com>

Patch Set 1
zram: a bit more robust