cpufreq: Retain only online cpus in managed_policy->cpus

cpufreq's handling of cpu online event can incorrectly initialize
managed_policy->cpus to include offline cpus. This causes cpufreq
governors to include offline cpus in their idle time computation, which
causes frequency to shoot up beyond normal levels (on systems where 2 or
more cpus need to be synchronized wrt frequency change).

This frequency shootup was not seen prior to commit 21111be8 which
changed idle time accounting for offline cpus. Prior to commit 21111be8,
idle time statistics for offline cpus would include their offline time
as well. Post commit 21111be8, offline time is not included in a cpu's
idle time statistics.

As a result, ondemand (or other cpufreq) governors would see unchanged
idle time for offline cpus, causing them to interpret those (offline)
cpus as 100% busy, which is wrong.

This patch fixes the issue by modifying cpufreq's hotplug handling to
retain only online cpus in managed_policy->cpus field. cpufreq governors
would then skip such offline cpus from idle time calculations.

Change-Id: Id2eba8c0ec3367609369b2e42a4e1386ff2e7ab5
Signed-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>
cpufreq: Fix optimal_freq logic on ramp down

When ondemand governor decides to ramp down the frequency, the missing
check for frequency being lower than optimal_freq was causing frequency
to be ramped down to optimal_freq even if the frequency decided by ondemand
governor was higher.

Change-Id: I00f9ae4c61ccda4039f3338dee2c29b8cb790be4
Signed-off-by: Veena Sambasivan <veenas@codeaurora.org>
cpufreq: intellidemand: Fix optimal_freq logic on ramp down

When ondemand governor decides to ramp down the frequency, the missing
check for frequency being lower than optimal_freq was causing frequency
to be ramped down to optimal_freq even if the frequency decided by ondemand
governor was higher.

Change-Id: I00f9ae4c61ccda4039f3338dee2c29b8cb790be4
Signed-off-by: Veena Sambasivan <veenas@codeaurora.org>
Signed-off-by: Paul Reioux <reioux@gmail.com>
cpufreq: Resolve CPUFREQ_NOTIFY issue

When the cpufreq_stat receives the frequency policy notification,
it checks if the frequency table and stats table are present for the cpu.
If both are present, it returns with -EBUSY error to the notification.
Due to this, none of the other registered modules receive this
notification.

If the stat table and sysfs nodes are already created, return 0 instead
of returning EBUSY error.

Change-Id: I1fd4a46e6a65edfc6253c4271288f10912ae2ad7
Signed-off-by: Archana Sathyakumar <asathyak@codeaurora.org>
msm: audio: qdsp6v2: Add size safety check to ACDB driver

Check that the size sent by userspace is not larger
then the internal amount allowed. This protects
against overflowing the stack due to an invalid size.

Change-Id: I8230fdb00a7b57d398929e8ab0eb6587476f3db1
CRs-fixed: 470222
Signed-off-by: Ben Romberger <bromberg@codeaurora.org>
msm: rq_stats: Fix missing initalization of cur_freq

Initialize cur_freq variable of each online cpu to the current
running cpu clock frequency. This avoids zeroing out the load
calculations until the first notification of the change in CPU
frequency comes in after CPUFREQ governors are intialized.

Also when a non boot cpu is up, update its cur_freq variable.

(cherry picked from commit 1633a48b16614e6b85c047a19ec93867c2ced3b3)

Change-Id: I950686deff02e2339eefae7d09392dda2174a545
CRs-fixed: 446017
Signed-off-by: Venkat Devarasetty <vdevaras@codeaurora.org>

Conflicts:
	arch/arm/mach-msm/msm_rq_stats.c
msm:rq_stats: Add hotplug disable attribute

Register for suspend and resume notifications from kernel. This should
be done as part of core_initcall so as to receive notification as close
as possible to the actual event. Add hotplug_disable attribute to
rq-stats node. Set/clear this attribute based on the suspend/resume events.

CRS-fixed: 452456
Change-Id: I76fee349b57f47df40785e9c2503e2e1cc6e064e
Signed-off-by: Archana Sathyakumar <asathyak@codeaurora.org>

Conflicts:
	arch/arm/mach-msm/msm_rq_stats.c
msm:rq_stats: Fix hotplug attribute during the suspend failure

If the system suspend fails, the hotplug_disable attribute remains
set. This prevents any change to core status from mpdecision. Reset
the value of this attribute if the module receives PM_POST_RESTORE
notification.

Change-Id: I22fd639134adbeb8f8f96603e285151480f537ec
Signed-off-by: Archana Sathyakumar <asathyak@codeaurora.org>
msm:rq_stats: Register for Cpufreq policy notification

Currently the load of the system is calculated using the max
frequency that is read during startup(It does not get updated
when the policy changes). As a result, the average load of the
system is incorrectly calculated and the system might not bring
the cpus online to manage the additional load. This
reduces the performance of the system.

To fix this issue, register rq_stats to receive cpufreq policy
notifications. Update the policy's max frequency when a
notification is received and use that value to calculate the load.

Change-Id: Icc78e28c736c170e198f723fd96c13dfb2dafe8a
Signed-off-by: Archana Sathyakumar <asathyak@codeaurora.org>
Signed-off-by: Anji Jonnala <anjir@codeaurora.org>
msm: footswitch-8x60: Skip GFX memory power collapse on 8064.

Update footswitch_disable to skip GFX memory power collapse on 8064 to avoid
any voltage droop on vddmx during GFX3D footswitch toggling.

As per hardware designer recommendations this would help to improve system
stability when responding to the inrush current event.

Change-Id: Ifa2f62629f0639d29f882d009dc5f4c10da46ca8
Signed-off-by: Shashank Mittal <mittals@codeaurora.org>
msm: cpufreq: Always update frequency limits when core is online

Remove condition in msm_cpufreq_init() so that when cpu is set to
online, it will call set_cpu_freq() and update the frequency limits.

CRs-Fixed: 462816
Change-Id: I40ac33c9cb4b42590a83f9d61b74f23379f5642e
Signed-off-by: Jennifer Liu <chihning@codeaurora.org>

Conflicts:
	arch/arm/mach-msm/cpufreq.c
block: urgent: Fix dispatching of URGENT mechanism

There are cases when blk_peek_request is called not from blk_fetch_request
thus the URGENT request may be started but the flag q->dispatched_urgent is
not updated.

Change-Id: I4fb588823f1b2949160cbd3907f4729767932e12
CRs-fixed: 471736
CRs-fixed: 473036
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>

Conflicts:
	block/blk-core.c
leds: Add LED trigger for thermal sensor

Add a thermal trigger named 'thermal' which activated by thermal
sensor.

Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
leds: Do not remove trigger when brightness = LED_OFF

Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
leds: Switch off LED when thermal trigger deactivated

Also initialize properly driver.

Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
usb: gadget: Fix a race condition in dynamic composition switching

This fix solves a race condition that causes a crash when switching
composition with USB cable disconnected.
The following race condition is fixed by protecting data->opened
with a mutex:

1. enable_store(0) is called.
2. While in enable_store(), adb_closed_callback() is invoked and
data->opened is set to false.
3. The execution is blocked on a mutex in closed_callback().
4. From adb_android_function_disable(), android_enable is invoked,
where we didn't call android_disable() just yet.

CRs-fixed: 482312
Change-Id: I7e37850a594e2e1c6d2cabbdb39760b00827afbd
Signed-off-by: Amit Blay <ablay@codeaurora.org>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
sched: LOAD_FREQ (4*HZ+61) avoids loadavg Moire. From http://ripke.com/loadavg/moire

Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
staging: prima: Disable debug

Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
staging: prima: Supress more trace messages

Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
cpufreq: stats: Don't stop notification call chain

The notification call chain is stopped if error returned. Since
no further steps is needed to handle such error, let's just print
a debug message here so the other registered cpufreq notifier can
be called correctly.

Signed-off-by: Lianwei Wang <a22439@motorola.com>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>