cpufreq: Avoid using smp_processor_id() in preemptible context

Even though this work item runs on only one cpu at a time (due to
queue_work_on()) it is possible for the work item to be preempted
and so use of smp_processor_id() is illegal.

BUG: using smp_processor_id() in preemptible [00000000]
code: kworker/3:1/4162 caller is dbs_refresh_callback+0xc/0x188
[<c00151b0>] (unwind_backtrace+0x0/0x120) from [<c0279058>]
(debug_smp_processor_id+0xbc/0xf0)
[<c0279058>] (debug_smp_processor_id+0xbc/0xf0) from [<c0454b54>]
(dbs_refresh_callback+0xc/0x188)
[<c0454b54>] (dbs_refresh_callback+0xc/0x188) from [<c0087290>]
(process_one_work+0x354/0x648)
[<c0087290>] (process_one_work+0x354/0x648) from [<c0089754>]
(worker_thread+0x1a8/0x2a8)
[<c0089754>] (worker_thread+0x1a8/0x2a8) from [<c008e480>]
(kthread+0x90/0xa0)
[<c008e480>] (kthread+0x90/0xa0) from [<c000f438>]
(kernel_thread_exit+0x0/0x8)

The intent of the code is to determine which CPU this work item
is running on, which we can easily do by passing that information
in a wrapper struct around the work struct. Do this so we avoid
this problem.

Change-Id: I05ca0ff2b3cbaa239930463ea0760e3e9d75145f
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
adapted for Intellidemand from CAF reference

Signed-off-by: faux123 <reioux@gmail.com>
intellidemand: Add support to consider other cpu load when scaling frequencies

Currently only current cpu load is considered when frequency scaling.
As a side effect of this when scheduler migrates a thread to a slower
core, the execution time increases unexpectedly.

The new algorithm not only considers current cpu load for frequency
scaling, but also takes into account load of other online cpus. The
treshold for this can be controlled using up_threshold_any_cpu_load.
When the up_threshold_any_cpu_load is crossed in any cpu then the
current cpu is set to sync_freq.

Also, when more than one cpu is online a two step ramp-up mechanism
is used. When the up_threshold_multi_core is crossed the cpu is ramped
up to optimal_freq which is less than policy->max and set to a power
friendly value.

Change-Id: I64bed1b142cde1f239e73aa1f78981c78aaf59ce
Signed-off-by: Narayanan Gopalakrishnan <nargop@codeaurora.org>

intellidemand: Fix kernel warning in cpufreq_governor_dbs

GOV_STOP event destroys the timer_mutex and is not initialized back
upon GOV_START event.
The Kernel complains at mutex_lock(during GOV_LIMITS event) after
mutex_destroy.

[<c0014918>] (unwind_backtrace+0x0/0x11c)
[<c007c004>] (warn_slowpath_common+0x4c/0x64)
[<c007c034>] (warn_slowpath_null+0x18/0x1c)
[<c079eef8>] (__mutex_lock_slowpath+0x130/0x3c4)
[<c079f1ac>] (mutex_lock+0x20/0x3c) from [<c0540900>]
[<c0540900>] (cpufreq_governor_dbs+0x3c8/0x468)
[<c053d500>] (__cpufreq_governor+0x90/0xe0)
[<c053d774>] (__cpufreq_set_policy+0x224/0x258)
[<c053da58>] (cpufreq_add_dev_interface+0x2b0/0x308)
[<c053e784>] (cpufreq_add_dev+0x500/0x56c)
[<c079247c>] (cpufreq_cpu_callback+0x88/0x9c)
[<c07a2ca8>] (notifier_call_chain+0x38/0x68)
[<c007ded0>] (__cpu_notify+0x28/0x40)
[<c0790024>] (_cpu_up+0xe4/0x118)
[<c0790024>] (cpu_up+0x64/0x80)
[<c0765840>] (store_online+0x48/0x78)
[<c038d0c8>] (dev_attr_store+0x18/0x24)
[<c017be40>] (sysfs_write_file+0x108/0x13c)
[<c012cdfc>] (vfs_write+0xb0/0x128)
[<c012d034>](sys_write+0x38/0x64)

Change-Id: Ie2a796b17209243de731ccf2ab04b7f9e7048df8
Signed-off-by: Anji Jonnala <anjir@codeaurora.org>

Adapted for Intellidemand from CAF reference

Signed-off-by: faux123 <reioux@gmail.com>
intellidemand: give intellidemand's cpu_dbs_info its own name

Signed-off-by: Paul Reioux <reioux@gmail.com>
intellidemand: add default values for dbs sync and optimal tuneables

Signed-off-by: faux123 <reioux@gmail.com>
Post proper response to SME when reassoc is rejected

When AP rejects reassoc request (i.e. status code other than 0), we
are posting an incorrect response (i.e. eWNI_SME_JOIN_RSP) to SME in
limSendDelStaCnf. Upon receiving this message, SME silently drops it
because it is in eCSR_ROAM_SUBSTATE_REASSOC_REQ sub-state and
expecting only eWNI_SME_REASSOC_RSP. Due to this, the upper layers do
not get informed about the link being torn down and the roaming engine
is also stuck in reassociating state. This leads to tx_timeouts being
reported by HDD.

This is being fixed by including eSIR_SME_FT_REASSOC_FAILURE in
limSendDelStaCnf so that correct response is posted to SME.
wlan: Release 3.2.1.11i

The following change was incorporated in this release:
===
Post proper response to SME when reassoc is rejected

When AP rejects reassoc request (i.e. status code other than 0), we
are posting an incorrect response (i.e. eWNI_SME_JOIN_RSP) to SME in
limSendDelStaCnf. Upon receiving this message, SME silently drops it
because it is in eCSR_ROAM_SUBSTATE_REASSOC_REQ sub-state and
expecting only eWNI_SME_REASSOC_RSP. Due to this, the upper layers do
not get informed about the link being torn down and the roaming engine
is also stuck in reassociating state. This leads to tx_timeouts being
reported by HDD.

This is being fixed by including eSIR_SME_FT_REASSOC_FAILURE in
limSendDelStaCnf so that correct response is posted to SME.
Update restart driver API to support statically linked WLAN driver

When WLAN driver is statically linked, the restart driver API will
invoke the WCNSS reset interrupt API to initiate SSR.
Notify the Kernel suspend to WCNSS

Notify WCNSS when WLAN driver has suspended; so that WCNSS need not
send certain notifications to Apps. It is only required to do this
when driver is in BMPS mode.
Conditionally invoke driver restart API

The API to restart the WLAN driver may not be available in all
kernels, so only try to invoke it if the kernel supports it.
wlan: Release 3.2.1.12

The following changes were incorporated in this release:
===
Update restart driver API to support statically linked WLAN driver

When WLAN driver is statically linked, the restart driver API will
invoke the WCNSS reset interrupt API to initiate SSR.
===
Notify the Kernel suspend to WCNSS

Notify WCNSS when WLAN driver has suspended; so that WCNSS need not
send certain notifications to Apps. It is only required to do this
when driver is in BMPS mode.
===
Conditionally invoke driver restart API

The API to restart the WLAN driver may not be available in all
kernels, so only try to invoke it if the kernel supports it.
===
Dump neighbor state info when scan is not allowed

This commit only adds a debug statement and supplements the changes
made previously.
Improve convergence of LFR roam candidate scan algorithm

When no roam candidates are found, the existing scan algorithm takes
long time to converge and there is no guarantee that all channels
will be scanned. This not only impacts power consumption, but also
affects roam convergence by not being able to find roam candidates
quickly. The algorithm is being modified as follows in an attempt
to address both power and convergence of the algorithm:
1. If no candidates were found for the very first time, re-register
with TL by lowering the lookup threshold by 3 dBm. Once look up DOWN
notification is received, we will scan on channels in the occupied
list followed by ALL valid channels not in the occupied list.
2. If still no candidates are found, start neighbor scan results
refresh timer (default is 20s). Upon expiry of the timer, once again
scan on channels in the occupied list followed by ALL valid channels
not in the occupied list.
3. If still no candidates are found, abort scanning and go back to
connected state. At this instant, only lookup UP event is registered
with TL.

This changelist includes the following:
a) Above mentioned scan algorithm.
b) Populate occupied list only with channels where candidates
matching the profile are found.
c) Initialize the occupied list only when a connection is made to
a profile different from the previous profile.
d) Use lookup UP threshold 2dB higher than lookup DOWN threshold.

NOTE: This change is being made ONLY for LFR.
De-register lookup UP indication during pre-auth

Upon receiving a lookup UP indication, it suggests that the link to the
current AP has improved and we clean-up all scan control info before
moving back to connected state. However, if we receive a lookup UP
indication while we are in the middle of a pre-auth, it can lead to
several race conditions:

1) Lookup UP indication received after SME posted pre-auth message
to PE and before PE posts the auth response back to SME.
In this instance, while SME layer cancels the pre-auth, the PE/LIM
would have created an FT session which goes unaccounted for. This extra
session causes subsequent scans to fail and eventually results in a
HB failure.

2) Lookup UP indication received after reassoc and before key exchange.
This instance is even more severe. When this happens, we would ignore
the connect indication received following key exchange. Due to this,
all layers except the neighbor roam engine has moved to the new AP
while the roam engine still thinks we are associated to the older AP.
Due to this mis-matched roam profile, we end up: (i) rejecting new
candidate APs found during scan, (ii) pre-auth with the AP we are
currently associated to, etc.

This is being fixed by de-registering for lookup UP indication
as soon as we receive the reassoc DOWN indication. If the pre-auth
fails with all available roam candidates, we once again register
for a lookup UP indication.
Only flush non-P2P results from scan cache prior to LFR scan

Currently, we flush the scan results from the scan cache prior to
LFR scans. This might unnecessarily purge P2P scan results and
might delay finding P2P clients in concurrency mode. This fix only
purges non-P2P clients prior to LFR scans.
Insure that LFR BG scanning is not performed for any non-Infra association

Insure that LFR BG scanning is not performed for any non-Infra
association. Modify csrRoamIsFastRoamEnabled() to check the persona
for the association. Return FALSE is the persona is not VOS_STA_MODE.
Remove call to palStopTimer for preauth

Remove call to palStopTimer in csrNeighborRoamPreauthRspHandler.
Fix driver hang in csrRoamRoamingStateDisassocRspProcessor

During roam, we disassociate with the current AP before reassociating
with the new one. Upon receiving the disassoc response from PE, we
look-up for the hand-off candidate in the scan results list to get
the Bss description. If this look-up fails, the current code is
unable to recover and leads to a driver hang. While it removes the
roam command from SME active queue, it does not reschedule another
one from the pending queue due to which no pending SME commands
get processed and the SME queue gets stuck.

The recovery mechanism is being fixed as follows:
1. Look-up for the hand-off candidate in the scan results list.
2. If the look-up fails, then we need to disconnect and clean-up.
a) For this, inform HDD about the roam failure and disconnect.
b) Post a disassoc request to PE with BSSID of hand-off candidate
so that it cleans-up the FT session that was created when pre-auth
was completed.
c) Upon receiving the disassoc response, call csrRoamComplete with
reason as eCsrJoinFailure so that SME layer cleans-up as well. This
also takes care of removing the roam command from the active queue
and schedules the next command from the pending queue, thereby
unblocking the SME layer.
Populate Correct Scan Mode for Roam

The init scan request in Riva is failing with reason code
"QWLANFW_STATUS_BMPS_NO_REPLY_TO_NULLFRAME_FROM_AP".  In Riva in case
of roaming, we should be ignoring the tx complete status and hence not
returning a failure when transmission of NULL frame to the AP
fails. However since the scan mode populated in the init scan request
sent from the host is incorrect we are seeing a failure. This fix is
to populate the scan mode in LIM to reflect a roaming type regardless
of the next state.
Send EDCA Parameters After Reassoc

The EDCA parameters are being sent down to Riva before receiving the
reassoc response, as a result all the values in the request are
zero. Send the EDCA parameters after re-assoc response is received.
Update csrRoamInitGlobals() to support static linking

For Nexus 4 the WLAN driver is statically linked.  On this platform it
was observed that occasionally if a P2P session was established, that
subsequently the HotSpot mode could not be enabled (reference Google
bug 7499425: Cannot enable WiFi-Tethering, if WiFi-Direct was
connected).  Analysis of the logs showed that CSR did not allow the
HotSpot session to be created because it thought another beaconing
session, namely a P2P GO session, was already active.  It turns out
that CSR utilizes a static global structure csrRoamRoamSession to
maintain per-session information.

On Product Lines where the WLAN driver is dynamically loaded this
static structure is reinitialized by the OS when the driver changes
modes of operation, since the driver will be reloaded when the mode
changes.  But when the driver is statically linked this static
structure is not reinitialized.  Hence when the driver changes from
STA + P2P mode to HotSpot mode, CSR believe P2P mode is still enabled.
Therefore modify csrRoamInitGlobals() to always initialize
csrRoamRoamSession before using it.  In addition delete two other
static structures, csrRoamPowerTableFromEeprom and
csrRoamPowerTableFromEeprom40MHz, which are no longer being used.