PM: devfreq: Fix simple_ondemand crashing on startup

Signed-off-by: Dan Trifan <jimsth@gmail.com>
msm: ocmem: Call restore_sec_config() after every power collapse

As the QRIB is enabled, after every power collapse of ocmem, the
QRIB is reset to the maximum security state. Due to this the apps
processor cannot access the ocmem register space.

The restore_sec_config() scm call needs to be called before any
register is accessed after a power collapse to ensure that the
security configuration is restored. The clocks need to be turned
on before every call that is made into TZ to ensure that there
is no power collapse.

CRs-Fixed: 651324, 660089
Change-Id: Ieb6b635142057e219de29e811c93749f6500cec5
Signed-off-by: Neeti Desai <neetid@codeaurora.org>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
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>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
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>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
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>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
ASoC: msm8974: Set tx bit rate for slim tx params

Set tx bit rate format in slimbus tx hw fixup params.

CRs-Fixed: 659408
Change-Id: I02b7cb88ca180cac033e9f5b63af287b2d932c10
Signed-off-by: Sudheer Papothi <spapothi@codeaurora.org>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
mmc: core: abort rescan if suspend is triggered

There could be a race between suspend and mmc_rescan as follows:
At resume:
-> mmc_pm_notify
  -> mmc_rescan is scheduled

Suspend is triggered:
-> mmc_pm_notify
   -> wait for mmc_rescan/cancel it
      -> rescan acquires wakelock if card is detected
         so as to give user-space a chance to respond
-> PM framework cancels suspend since wakelock is active

Hence, release the wake-lock if its active in suspend prepare
and check for rescan_disable before acquiring wake-lock.
This prefers suspend over notifying the user-space of the status
of the card, which is fine since with suspend user-space is frozen
too.

CRs-fixed: 655281
Change-Id: I83783589f9b541d3af73931e9a7b0b144a25538e
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
ASoC: msm: ensure check before accessing session private data.

The compressed session needs to be active to set volume to dsp.
Ensure the check to see valid session exist before accessing
private data, else results in kernel panic.

The Memory allocation for driver data also needs to be freed
for failure in session open.

CRs-Fixed: 638817
Change-Id: Ifdce543aa55df420960e9eeff0564f18d9410060
Signed-off-by: Asish Bhattacharya <asishb@codeaurora.org>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
ASoC: wcd9xxx: Add check for buffer overflow

Current code does not check if the indexes of array
codec_dai being accessed is within the maximum
number of codec dais for a particular codec. The change
adds this check and ensures that indexes outside the
bounds of array are not accessed.

CRs-Fixed: 628865
Change-Id: Ibf81f91b35e43feddc6b03a1239b4d12e04a95da
Signed-off-by: Aravind Kumar <akumark@codeaurora.org>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
ASoC: wcd9xxx: Clear unsupported jack from hph status

In the case when headphone or headset is removed at the
other end of extension cable, unsupported jack event is
never cleared. Further headset/headphone insertion event
will always have the unsupported jack bit ON in the hph_status.

Change-Id: I5ea046b09cf8db4702c2e6d97fa1c8d23ba2702c
Signed-off-by: Phani Kumar Uppalapati <phaniu@codeaurora.org>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
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>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
cpufreq: cpu-boost: Consider only task load to decide on sync frequency

Currently we take the maximum between the source CPU frequency and
the calculated frequency based on the migrating task load to decide on
the frequency to sync the destination CPU to. This was done to handle
short bursts in workloads of tasks which migrated immediately after
causing a ramp up on the source CPU. Since their load history wasn't
high enough, the destination CPU synced to a lower frequency which
wasn't sufficient for the spike in workload.

But as such cases are rare, taking the higher of source and calculated
frequency can lead to destination CPU unnecessarily spending a
considerable amount of time at higher frequencies which in turn can
hurt power.

With this change we make sure only the migrating task load is used
to calculate the sync frequency for destination CPU when load based
syncing is enabled.

Change-Id: Ib1489d256c42ea7712aad2179aebffc87c549836
Signed-off-by: Girish Ghongdemath <girishsg@codeaurora.org>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
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>
Signed-off-by: Dan Trifan <jimsth@gmail.com>