msm: acpuclock-8974: Modify L2 table for 8974

Currently 1.26 GHz and 1.49 GHz in the L2 tables for 8974
map to 800 MHz DDR. With this change the above frequencies
now get mapped to 614 MHz DDR. This change maps the above
two frequencies to lower DDR and will thereby help save power
for use cases which spend majority of time at above frequencies.

Change-Id: I7f1cbc12ff7dae28f65863d5c41e68de2db40bfe
Signed-off-by: Dilip Gudlur <dgudlur@codeaurora.org>
msm: cpufreq: Relax constraints on "msm-cpufreq" workqueue

This workqueue is not used in memory reclaim paths, so the
WQ_MEM_RECLAIM flag is not needed. Additionally, there is no
need to restrict the queue to having one in-flight work item.
Remove these constraints.

Change-Id: I9edde40917d3ec885ce061133de20680634321d0
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
msm: cpufreq: Ensure cpufreq change happens on corresponding CPU

* This removes stuttering a few ppl were experiencing -imoseyon

Checking the cpus_allowed mask of the current thread before changing the
frequency doesn't guarantee that the rest of the execution will continue on
the same CPU. The only way to guarantee this is to schedule a work on the
specific CPU and also prevent hotplug  of that CPU (already done by
existing code).

Change-Id: I51a02fcc777a47d3c16f2d83c47e96f2c59f7ae6
Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
block: row-iosched idling triggered by readahead pages

In the current implementation idling is triggered only by request
insertion frequency. This heuristic is not very accurate and may hit
random requests that shouldn't trigger idling. This patch uses the
PG_readahead flag in struct page's flags, which indicates that the page
is part of a readahead window, to start idling upon dispatch of a request
associated with a readahead page.

The above readehead flag is used together with the existing
insertion-frequency trigger. The frequency timer will catch read requests
which are not part of a readahead window, but are still part of a
sequential stream (and therefore dispatched in small time intervals).

Change-Id: Icb7145199c007408de3f267645ccb842e051fd00
Signed-off-by: Lee Susman <lsusman@codeaurora.org>
block: row: Remove warning massage from add_request

Regular priority queues is marked as "starved" if it skipped a dispatch
due to being empty. When a new request is added to a "starved" queue
it will be marked as urgent.
The removed WARN_ON was warning about an impossible case when a regular
priority (read) queue was marked as starved but wasn't empty. This is
a possible case due to the bellow:
If the device driver fetched a read request that is pending for
transmission and an URGENT request arrives, the fetched read will be
reinserted back to the scheduler. Its possible that the queue it will be
reinserted to was marked as "starved" in the meanwhile due to being empty.

CRs-fixed: 517800
Change-Id: Iaae642ea0ed9c817c41745b0e8ae2217cc684f0c
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
mm: pass readahead info down to the i/o scheduler

Some i/o schedulers (i.e. row-iosched, cfq-iosched) deploy an idling
algorithm in order to be better synced with the readahead algorithm.
Idling is a prediction algorithm for incoming read requests.

In this patch we mark pages which are part of a readahead window, by
setting a newly introduced flag. With this flag, the i/o scheduler can
identify a request which is associated with a readahead page. This
enables the i/o scheduler's idling mechanism to be en-sync with the
readahead mechanism and, in turn, can increase read throughput.

Change-Id: I0654f23315b6d19d71bcc9cc029c6b281a44b196
Signed-off-by: Lee Susman <lsusman@codeaurora.org>
msm: krait-regulator-pmic: Add krait-regulator-pmic driver

Read the register configurations of regulators in the gang and
bug if the gang is not setup correctly.

Importantly, fix the voltage overshoots observed during PFM-PWM
transitions by implementing the following steps.

PFM -> PWM
After the buck is set to PWM mode, wait 50uS and then set the PWM
current limit to 3.5A.

PWM -> PFM
After the buck is set to pfm mode, immediately lower the PWM current limit
to 2A (no delay required).

Change-Id: I15af09aaf8427e75253a4e12878ee1f0a1265454
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>

Conflicts:

	arch/arm/mach-msm/Makefile
msm: krait-regulator: switch mode on the same cpu

The driver currently runs LDO-BHS mode switches while possibly
running on a different CPU. The CPU for which the mode switch is
issued could be running its SPM sequence as a part of going in or
coming out of power collapse. The LDO-BHS switching executed from a
different CPU could race with the mode switches done in SPM sequence
leaving the CPU in a bad state.

Fix this by executing LDO-BHS mode switches on the target CPU. This
guarantees that the SPM sequence won't be running on that CPU while
changing modes.

CRs-Fixed: 523449
Change-Id: I863ce3bcd6dd9ba3155c4573071f01e7a020ef48
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
msm: krait-regulator: rename online to reg_en

The online variable is confusing, since it does not mean whether
the core is online or offline. It actually used to indicate whether
the regulator is enabled or disabled.
Change the variable name to indicate so.

Change-Id: I20c270162df57cf81c17e808d383880b5b2e4eef
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
msm: krait-regulator: fix race conditions in regulator enable/disable

The driver suffers from the following race conditions:
* when a core is being onlined and is in its PREPARE_UP stage regulator
enable for that core is called. This call may cause a switch between
ldo-bhs but since the core if not online yet and ldo-bhs calls are
strictly executed on the target cpu - this leads to smp function calls
to fail.
* before the core in onlined and after the PREPARE_UP stage there could
be another frequency change that causes a gang voltage change that in turn
causes this core to switch states. This too leads to failed smp function
calls since they are targeted towards offline core
* when a cpu is offlined but a DEAD notification is not sent a frequency
change on another core may cause a switch on this cpu. This also leads
to failed smp function calls on offline core.

Fix the above by forcing the core to BHS when it is in its transitory
phase and while it is offlined. In other words a core will switch to
bhs/ldo based on the voltage requests only between CPU_ONLINE and
CPU_DOWN_PREPARE notifications. A core can run on BHS if it
can run on LDO since LDO just acts as a voltage step down, the core
can run when fed higher voltage from BHS.

To do this add hooks to get cpu hotplug notifications in the driver and
appropriately force bhs or switch to ldo or bhs based on gang voltage.

CRs-Fixed: 529593
Change-Id: I7210f62072853ed6f807df2d78bc2144f67eaf31
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
msm: hotplug: remove code related to cpu_killed

Earlier the completion event cpu_killed was used to synchronize
notify to hot plug framework that the CPU is dead. But now it is
replaced with another completion event cpu_died and it is placed
in the hotplug framework itself. So there is no need for a
platform to implement a completion event.

But in msm platform driver the completion event related code
was not removed with the changes in hotplug framework. This
patch removes the unused code.

Change-Id: I4418e5e397821e39a7b6a6efa997c4a866e9b46b
Signed-off-by: Venkat Devarasetty <vdevaras@codeaurora.org>
msm: socinfo: fix memory leak in socinfo_init_sysdev

Under certain error paths in socinfo_init_sysdev the soc_dev_attr
struct does not get freed. Fix this memory leak.

Change-Id: I22a4b60722367798dc5171fe7c00fc7c814168cb
Signed-off-by: Syed Rameez Mustafa <rameezmustafa@codeaurora.org>
msm: msm_bus: Fix the type error causing bandwidth overflow

On legacy chipsets, long int was being used to store
return value after calculating interleaved bw. However,
NoCs support 64-bit integers ab/ib values. problme occurs
if client request for higher bw and if difference of ab
value exceeds the range of 32 bit integer, the Value
overflows and turns negative, which leads to wrong bw calculation.

This patch fixes this integer overflow by correcting argument
type to store bw.

CRs-Fixed: 537213
Change-Id: I8c6c79ba245a988c2c54ccaca3f3eaf5cb857ce5
Signed-off-by: Alok Chauhan <alokc@codeaurora.org>
msm: msm_bus: send correct value to bw division function

While calculating bw for existing client request
sometimes it can go to negative if client unregisters
or send request with lesser ab/ib values. Bus driver
will divide bandwidth if interleaving enabled.

Added a macro wrapper to handle negative bw values
since the division utility function can't handle
negative values

CRs-Fixed: 521940
Change-Id: Ic3a216b8efb535593fe02ad3228d71808d2e0f98
Signed-off-by: Alok Chauhan <alokc@codeaurora.org>
msm: msm_bus: Don't touch ID array in case of invalid IDs

Protect the bus ID array in case config data contains invalid
IDs which can cause out-of-bounds access.

Change-Id: I6cde56b8563598abf4668f709fe710af2b9938fd
CRs-Fixed: 515761
Signed-off-by: Gagan Mac <gmac@codeaurora.org>
msm: msm_bus: Add checks during bus client unregistration

During unregistration clients should withdraw all pending
requests. This was earlier done in update-request function.
However, that caused acpuclock client requests to be
incorrectly zeroed out.

It seems more appropriate to let the client ensure that
they correctly clean up their requests than to have bus
driver forcefully remove non-zero requests. Hence, a
warning has been added in the unregistration path.

Change-Id: Icfd4f62f46fdd3219dc685007029be21b983c2d0
CRs-Fixed: 510389
Signed-off-by: Gagan Mac <gmac@codeaurora.org>
msm: msm_bus: Correct the return value from register-client

On failure, return 0, and not a non-zero value as that can
be interpreted as a valid client ID.

Change-Id: I7a5b448bc398b4a4792170147a5e5317d25f8b3c
CRs-Fixed: 486328
Signed-off-by: Gagan Mac <gmac@codeaurora.org>
mmc: msm_sdcc: Remove unnecessary delay in interrupt context

msmsdcc_request_end when called with interrupts disabled inside an
interrupt handler adds an unnecessary 5ms delay on command timeouts,
which impacts system performance. Remove this delay.

Change-Id: I90aec109fe84f7b9f9a9362b5ee2d8d1310833af
Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
cfg80211: Fix memory leak

When a driver requests a specific regulatory domain after cfg80211 already
has one, a struct ieee80211_regdomain is leaked.

Change-Id: Id28fc9861b9c911a97bd242439eabca097d76258
Reported-by: Larry Finger <Larry.Finger@lwfinger.net>
Tested-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Git-commit: b7566fc363e23f0efd3fa1e1460f9421cdc0d77e
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
[mattw@codeaurora.org: trivially backport to the msm-3.4 kernel]
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
sync: Fix a race condition between release_obj and print_obj

Before this change, a timeline would only be removed from the timeline
list *after* the sync driver had its release_obj() called. However, the
driver's release_obj() may free resources needed by print_obj().

Although the timeline list is locked when print_obj() is called, it is
not locked when release_obj() is called. If one CPU was in print_obj()
when another was in release_obj(), the print_obj() may make unsafe
accesses.

It is not actually necessary to hold the timeline list lock when calling
release_obj() if the call is made after the timeline is unlinked from
the list, since there is no possibility another thread could be in --
or enter -- print_obj() for that timeline.

This change moves the release_obj() call to after the timeline is
unlinked, preventing the above race from occurring.

Signed-off-by: Alistair Strachan <alistair.strachan@imgtec.com>