kthread_worker: reorganize to prepare for flush_kthread_work() reimplementation

Make the following two non-functional changes.

* Separate out insert_kthread_work() from queue_kthread_work().

* Relocate struct kthread_flush_work and kthread_flush_work_fn()
  definitions above flush_kthread_work().

v2: Added lockdep_assert_held() in insert_kthread_work() as suggested
    by Andy Walls.

Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Andy Walls <awalls@md.metrocast.net>
kthread_worker: reimplement flush_kthread_work() to allow freeing the work item being executed

kthread_worker provides minimalistic workqueue-like interface for
users which need a dedicated worker thread (e.g. for realtime
priority).  It has basic queue, flush_work, flush_worker operations
which mostly match the workqueue counterparts; however, due to the way
flush_work() is implemented, it has a noticeable difference of not
allowing work items to be freed while being executed.

While the current users of kthread_worker are okay with the current
behavior, the restriction does impede some valid use cases.  Also,
removing this difference isn't difficult and actually makes the code
easier to understand.

This patch reimplements flush_kthread_work() such that it uses a
flush_work item instead of queue/done sequence numbers.

Signed-off-by: Tejun Heo <tj@kernel.org>
Revert "ARM: hammerhead: turn off android logger"

This reverts commit a133cb7020104dcce4d9e46a9b7b304f1dfb09cc.
ARM: Flush the caches for non panicking CPUs in case of a kernel panic

In case of a kernel panic, only the panicking CPU does an entire
cache flush. This means that certain dirty cache lines in the L1
caches of the other CPUs may never get flushed. This gives us
improper RAM dumps. Add cache flushing for all the online CPUs.
The outer domain is not flushed since it is already being done by
the panicking CPU.

Change-Id: Ibf844ecf6b4dbc3c623789f72a26936aeb4a7306
Signed-off-by: Syed Rameez Mustafa <rameezmustafa@codeaurora.org>
ARM: smp: Save CPU registers before IPI_CPU_STOP processing

When a kernel panic occurs on one CPU, other CPUs are instructed to stop
execution via the IPI_CPU_STOP message. These other CPUs dump their stack,
which may not be good enough to reconstruct their context to perform
post-mortem analysis. Dump each CPU's context
(before it started procesing the IPI) into a globally accessible structure
to allow for easier post-mortem debugging.

Change-Id: I68ac75f73d7ddaebaff9122b23e341bcb00e8fb9
Signed-off-by: Tingting Yang <tingting@codeaurora.org>
ARM: smp: fix incorrect per-cpu definition of regs_before_stop

The commit efd002896a3636a4d1606ac0630aaafbbfdea9aa introduced changes
to store CPU registers for all CPUs that handle IPI_CPU_STOP. The
structure to save the registers was intended to be a per-cpu variable.
However, the patch did not allocate a per-cpu structure and instead only
ended up providing a compiler per-cpu directive. Fix this bug by actually
defining a static per-cpu variable.

Change-Id: Ifd192223c135025897e10312f61b108757575068
Signed-off-by: Syed Rameez Mustafa <rameezmustafa@codeaurora.org>
ARM: smp: BUG() if smp_send_reschedule() is called for an offline cpu

Sending an IPI_RESCHEDULE to an offline CPU is incorrect and potentially
bad for both power and stability. On some sub-architectures such as MSM,
if a power-collapsed CPU is unexpectedly woken up by an IPI, it will be
begin executing without the preparations that would normally happen as
part of CPU_UP_PREPARE. If clocks, voltage regulators, or other hardware
configuration are not performed, the booting CPU may cause general
instability or (at best) poor power performance since the CPU would be
powered up but not utilized.

One common cause for such issues is misuse of add_timer_on() or APIs
such as queue_work_on() which call it. If proper precautions are not
taken to block hotplug while these APIs are called then a race may
result in IPIs being sent to CPUs that are already offline.

This same argument could be applied to other IPIs (with the exception
of IPI_WAKEUP), but the others are already restricted to only online
CPUs by existing mechanisms, so an explicit assertion is not useful.

Change-Id: I437db112e7e2fa7c0635e4e97e265692621944f1
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
msm: perf: tracectr: Initialize cnts after hotplug

Due to the mismatch between counter values saved across CPU hotplug
by perf and tracecounter logic, incorrect values are calculated for
first entry in trace buffer.
Ignore the first entry when CPU comes out of hotplug and set previous
counter values in this scenario.

Change-Id: Ieeeaa301d713f338f11f6e84aeb984a3708e45fc
Signed-off-by: Sheetal Sahasrabudhe <sheetals@codeaurora.org>
Perf: Reset pmu after hotplug

The counter enable bits were staying in undefined state after CPU
came out of hotplug when perf was not enabled.
This was resulting into non-zero values for counters in ftrace buffer
which were not enabled by perf.
Clear the pmu when CPU comes out of hotplug and perf is not enabled.

Change-Id: I31e17565ad914650a12102a5c359b363f8f2ca2a
Signed-off-by: Sheetal Sahasrabudhe <sheetals@codeaurora.org>
msm: perf: set filter bits for cycle counter on krait

When programming the cycle counter on krait, the filter
register needs to be programmed in order to set the
usermode/kernelmode filter options.

Change-Id: Ifd5b032c9a5df4821706438d4359f84d8f614468
Signed-off-by: Neil Leeder <nleeder@codeaurora.org>