mach-msm: dyn_hotplug: Remove debug info

Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
mach-msm: dyn_hotplug: Add checks in parameters set

Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
mach-msm: dyn_hotplug: Add max_online parameter

Add max_online tunable (default value 4) to control the max possible
online CPUs.

Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>

Conflicts:

	arch/arm/mach-msm/dyn_hotplug.c

Modified max_online to 2 for 8660
mach-msm: dyn-hotplug: Use macros for down_timer and up_timer thresholds

Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>

Conflicts:

	arch/arm/mach-msm/dyn_hotplug.c
mach-msm: dyn_hotplug: Add some comments

Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
mach-msm: dyn_hotplug: Number of online CPUs have to be above min_online

Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
mach-msm: dyn-hotplug: Bring only each possible CPU on late resume

Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
mach-msm: dyn_hotplug: Fix CPU freq stats on calling down_all

Also call up_all and down_all from set_min_online and set_max_online
only if the driver is enabled.

Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
mach-msm: dyn_hotplug: Offline the CPU with the lowest current frequency

Thanks to Skkip for the idea.

Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
mach-msm: dyn_hotplug: Schedule driver work only on CPU0

CPU0 is always online.
So, schedule driver's work only on CPU0 to avoid migration
to other CPUs.

Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
mach-msm: dyn_hotplug: Fix checkpatch error

Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
mach-msm: dyn_hotplug: On early suspend use min_online value of 1

It seems that C3 power state on CPU0 is used only if all other
CPUs are offline.
During early_suspend use the min_online value of 1 to ensure
that during wakelocks C3 power state may be used on CPU0
On early_resume restore the saved min_online value.

Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
mach-msm: dyn_hotplug: Use cpumask_next_zero to find the next offline CPU

Use more elegant way to find the next offline CPU.
Thanks to Skkip for sharing.

Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
cpufreq: ondemand: Boost CPU frequency only for touch input

Originally CPU frequency were boosted for any input event.
In some case, sensor sends a lot of input event, which
keep CPU in high frequency.  CPU frequency only need to
be boosted when real user interaction happens.

Change-Id: Ia3ad755b98d8363a17729926610b5dd6f0075288
CR-Fixed: 507519
Signed-off-by: Tingwei Zhang <tingwei@codeaurora.org>
cpufreq: ondemand: Fix update_sampling_rate race with hotplug

update_sampling_rate has a for loop which goes through each
online cpu and possibly queue up the ondemand work for them.
But while doing this it doesnt take any hotplug lock which
could potentially cause a race condition where ondemand work
is queued after the hotplug code (which sets the policy to NULL)
in the governor has cancelled any pending work. This could cause
a crash while trying to access the NULL policy in dbs_check_cpu.

Protecting the for_each_online_cpu loop with get_online_cpus()
and put_online_cpus().

Change-Id: Ia3f43ca7e4bed542834ab03ca1191d728f13311c
Signed-off-by: Rohit Gupta <rohgup@codeaurora.org>
cpufreq: ondemand: Fix store_powersave_bias() race with hotplug

store_powersave_bias() assumes that CPUs will not be taken offline or
brought online while executing its for_each_online_cpu() loops. Fix
this race by blocking hotplug while executing in these loop.

CRs-Fixed: 494407
Change-Id: I0d5520444ec21a8d9b12fb73c06ac8442449fa85
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
cpufreq: ondemand: Fix locking in store_powersave_bias

store_powersave_bias() assumes that dbs_info->cur_policy will
not change while it is executing. If it does, memory corruption
can potentially result. Fix this by acquiring the dbs_lock.

Most noticeably, this resolves timer-related list corruptions
encountered when queue_delayed_work_on() is called from within
store_powersave_bias() while a CPU is being hotplugged in and
out.

CRs-Fixed: 494407
Change-Id: I0fd5cbef6834545274cad9481e574ec50b37b871
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
cpufreq: ondemand: Fix locking issue in store_powersave_bias

store_powersave_bias takes timer_mutex before calling dbs_timer_exit
which tries to cancel the delayed work do_dbs_timer which in turn
tries to take the same lock. This can cause a lock recursion under
the race condition where can cancel_delayed_work_sync is called
when the work has already started executing.

This can be avoided by taking that lock after calling
dbs_timer_exit.

Change-Id: I7f862286e66f1ddc1e13e4eeee369dd188fc10d5
Signed-off-by: Rohit Gupta <rohgup@codeaurora.org>
cpufreq: ondemand: Fix hotplug deadlock with store_powersave_bias

store_powersave_bias() acquires the hotplug lock and the dbs_mutex
lock, but does so in the wrong order.  Deadlocks like the following
can result.

Thread A:
    get_online_cpus+0x3c/0x5c           <- acquires 'cpu_hotplug.lock'
    store_powersave_bias+0x80/0x3f4     <- acquires 'dbs_mutex'
    kobj_attr_store+0x14/0x20
    sysfs_write_file+0x108/0x13c
    vfs_write+0xb0/0x128
    sys_write+0x38/0x64

Thread B:
    cpufreq_governor_dbs+0x7c/0x55c     <- acquires 'dbs_mutex'
    __cpufreq_governor+0x90/0xe0
    __cpufreq_set_policy+0x1b0/0x258
    cpufreq_add_dev_interface+0x2cc/0x334
    cpufreq_add_dev+0x514/0x580
    cpufreq_cpu_callback+0x88/0x9c
    notifier_call_chain+0x38/0x68
    __cpu_notify+0x28/0x40
    _cpu_up+0xe4/0x118                  <- acquires 'cpu_hotplug.lock'
    cpu_up+0x64/0x80
    store_online+0x48/0x78
    dev_attr_store+0x18/0x24
    sysfs_write_file+0x108/0x13c
    vfs_write+0xb0/0x128
    sys_write+0x38/0x64

Fix this by flipping the order in which the locks are acquired and
released in store_powersave_bias so that it is the same as in the
hotplug path.

Change-Id: Idc59fb29d60b8f7fceb8ed0f2bb9eff4670abda7
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
msm: pm: send notification only for SPC and PC

Currently the pm notification is sent for all the low power
modes of each CPU. Generally the subscriber to this notification
expects to be notified for core power collapse. For example
interrupt controller subscribes this notification to save
and restore its context when entering and exit power collapse
respectively. So this is not necessary for shallow power modes
like WFI and Retention.

This change is to send the notification for only standalone
power collapse of each core and idle power collapse of core0.

Change-Id: I39fb6a6bfb47ca49d6ec8df8cad1fd74424140a0
Signed-off-by: Venkat Devarasetty <vdevaras@codeaurora.org>

Conflicts:

	arch/arm/mach-msm/cpuidle.c