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>

Conflicts:
	arch/arm/mach-msm/perf_debug.c
	arch/arm/mach-msm/perf_trace_counters.c
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>

Conflicts:
	arch/arm/kernel/perf_event.c
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>
smp: Allow booting a specific subset of CPUs

In a heterogenous multiprocessor system, specifying the
'maxcpus' parameter on the kernel command line does not
provide sufficient control over which CPUs are brought
online at kernel boot time, since CPUs may have nonuniform
performance characteristics. Thus, we introduce a
'boot_cpus' command line argument, allowing the user to
explicitly specify the list of CPUs that shall be brought
online during kernel boot.

Change-Id: I5f119e23202660941fa7be8c4e6dd91a82365451
Signed-off-by: Stepan Moskovchenko <stepanm@codeaurora.org>
perf: Prevent false warning in perf_swevent_add

The perf cpu offline callback takes down all cpu context
events and releases swhash->swevent_hlist.

This could race with task context software event being just
scheduled on this cpu via perf_swevent_add while cpu hotplug
code already cleaned up event's data.

The race happens in the gap between the cpu notifier code
and the cpu being actually taken down. Note that only cpu
ctx events are terminated in the perf cpu hotplug code.

It's easily reproduced with:
  $ perf record -e faults perf bench sched pipe

while putting one of the cpus offline:
  # echo 0 > /sys/devices/system/cpu/cpu1/online

Console emits following warning:
  WARNING: CPU: 1 PID: 2845 at kernel/events/core.c:5672 perf_swevent_add+0x18d/0x1a0()
  Modules linked in:
  CPU: 1 PID: 2845 Comm: sched-pipe Tainted: G        W    3.14.0+ #256
  Hardware name: Intel Corporation Montevina platform/To be filled by O.E.M., BIOS AMVACRB1.86C.0066.B00.0805070703 05/07/2008
   0000000000000009 ffff880077233ab8 ffffffff81665a23 0000000000200005
   0000000000000000 ffff880077233af8 ffffffff8104732c 0000000000000046
   ffff88007467c800 0000000000000002 ffff88007a9cf2a0 0000000000000001
  Call Trace:
   [<ffffffff81665a23>] dump_stack+0x4f/0x7c
   [<ffffffff8104732c>] warn_slowpath_common+0x8c/0xc0
   [<ffffffff8104737a>] warn_slowpath_null+0x1a/0x20
   [<ffffffff8110fb3d>] perf_swevent_add+0x18d/0x1a0
   [<ffffffff811162ae>] event_sched_in.isra.75+0x9e/0x1f0
   [<ffffffff8111646a>] group_sched_in+0x6a/0x1f0
   [<ffffffff81083dd5>] ? sched_clock_local+0x25/0xa0
   [<ffffffff811167e6>] ctx_sched_in+0x1f6/0x450
   [<ffffffff8111757b>] perf_event_sched_in+0x6b/0xa0
   [<ffffffff81117a4b>] perf_event_context_sched_in+0x7b/0xc0
   [<ffffffff81117ece>] __perf_event_task_sched_in+0x43e/0x460
   [<ffffffff81096f1e>] ? put_lock_stats.isra.18+0xe/0x30
   [<ffffffff8107b3c8>] finish_task_switch+0xb8/0x100
   [<ffffffff8166a7de>] __schedule+0x30e/0xad0
   [<ffffffff81172dd2>] ? pipe_read+0x3e2/0x560
   [<ffffffff8166b45e>] ? preempt_schedule_irq+0x3e/0x70
   [<ffffffff8166b45e>] ? preempt_schedule_irq+0x3e/0x70
   [<ffffffff8166b464>] preempt_schedule_irq+0x44/0x70
   [<ffffffff816707f0>] retint_kernel+0x20/0x30
   [<ffffffff8109e60a>] ? lockdep_sys_exit+0x1a/0x90
   [<ffffffff812a4234>] lockdep_sys_exit_thunk+0x35/0x67
   [<ffffffff81679321>] ? sysret_check+0x5/0x56

Fixing this by tracking the cpu hotplug state and displaying
the WARN only if current cpu is initialized properly.

Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: stable@vger.kernel.org
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Jiri Olsa <jolsa@redhat.com>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1396861448-10097-1-git-send-email-jolsa@redhat.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
net: wireless: bcmdhd: Use powersuspend to prevent panic

* Currently code is checking for deprecated early suspend
  which we don't have 3.4 onwards.
* So helper function is called for checking suspend status.
* This is causing race condition if screen is turned on and off
  rapidly.

Happy Case:
Screen Off -> Wifi Suspended -> Screen On -> Wifi Resumed

Race conditon:
Screen Off -> Wifi Suspended -> Screen On -> Wifi Resumed
-> Screen Off -> Screen On (rapid) -> Wifi Suspended!!

This causes watchdog bark / kernel panic as below:

[ 7217.522130] PM: noirq resume of devices complete after 4.327 msecs
[ 7217.527345] PM: early resume of devices complete after 2.901 msecs
[ 7217.549827] PM: resume of devices complete after 22.455 msecs
[ 7217.551660] Restarting tasks ... done.
[ 7217.558636] PM: suspend exit 2014-05-28 06:29:43.989676647 UTC
[ 7221.016418] [Touch] touch on
[ 7221.217701] mdss_dsi_panel_on
[ 7221.267290] lm3630_backlight_on
[ 7221.292473] dhd_set_suspend: Remove extra suspend setting
[ 7225.155909] lm3630_backlight_off
[ 7225.231024] [prevent_touchscreen_sleep]: payload = 10
[ 7225.383173] mdss_dsi_panel_off:
[ 7225.406145] [Touch] touch off
[ 7226.303258] [Touch] touch on
[ 7226.497452] mdss_dsi_panel_on
[ 7227.373713] [prevent_touchscreen_sleep]: payload = 10
[ 7227.525721] mdss_dsi_panel_off:
[ 7227.548667] [Touch] touch off
[ 7229.718552] [Touch] touch on
[ 7229.917659] mdss_dsi_panel_on
[ 7235.208821] dhd_set_suspend: force extra Suspend setting
[ 7235.220861] dhd_get_suspend_bcn_li_dtim beacon=100 bcn_li_dtim=3 DTIM=1 Listen=10
[ 7241.483289] Watchdog bark! Now = 7241.483285
[ 7241.483342] Watchdog last pet at 7220.296271
[ 7241.483428] cpu alive mask from last pet 0
[ 7241.483474] Causing a watchdog bite! IRQ = 35.

No errors detected
Boot info:
Last boot reason: wdog_bark

Let's use powersuspend driver replacing deprecated earlysuspend drivers.

CAUTION: Powersuspend driver shouldn't use screen on/off hooks else this
         patch is of no use!! If you really want screen on/off level of
         sensitivity, use LCD notifier for such drivers.

Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
net: wireless: bcmdhd: Remove noisy message

Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>