cpufreq: fix utilization statistics for sync cpus

If the cpus are using related_cpus policy, then the
current implementaion will overwrite the the calculated
load for every iteration in the for loop. Hence, mpdecision
will read incorrect value, if the cores are using related
cpus policy. With this change mpdecision will read the
sum of the loads of all cpu's, if related cpu policy is
used.

Change-Id: I242c8fe39fd75dc3e48750a5b78a5d218b536ddd
Signed-off-by: Narayanan Gopalakrishnan <nargop@codeaurora.org>
Signed-off-by: Shruthi Krishna <skrish@codeaurora.org>
vfp: build for neon
config: ntfs, nfs, ksm
cpufreq: fix utilization statistics for sync cpus

If the cpus are using related_cpus policy, then the
current implementaion will overwrite the the calculated
load for every iteration in the for loop. Hence, mpdecision
will read incorrect value, if the cores are using related
cpus policy. With this change mpdecision will read the
sum of the loads of all cpu's, if related cpu policy is
used.

Change-Id: I242c8fe39fd75dc3e48750a5b78a5d218b536ddd
Signed-off-by: Narayanan Gopalakrishnan <nargop@codeaurora.org>
Signed-off-by: Shruthi Krishna <skrish@codeaurora.org>
cpufreq: fix interactive bug during hotplug

When a new cpu is added and if does not enter idle
for long, the interactive timer is not started and hence
the cpu remains at lowest frequecny, despite the system
load. This impacts mainly benchmarks. Starting a timer
at governor start to handle low frequency.

Change-Id: I8ac9705b9f166a95715c985efacd2ae8ef387cb7
Signed-off-by: Narayanan Gopalakrishnan <nargop@codeaurora.org>
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>
cpufreq: interactive: Fix blocked task warnings

Running a kernel that never enables the interactive cpufreq
will eventually hit the following warning:

INFO: task kinteractiveup:112 blocked for more than 120 seconds.
kinteractiveup  D c07ae3a4  7072   112      2 0x00000000
[<c07ae3a4>] (__schedule+0x4e4/0x5c4) from [<c00a1b8c>] (kthread+0x70/0x94)
[<c00a1b8c>] (kthread+0x70/0x94) from [<c000f368>]
(kernel_thread_exit+0x0/0x8)

due to the fact that the kthread is never woken up after being
forked. Kick the thread to its idle loop so that it can
schedule() and move out of the D state.

Change-Id: Idc490e707d9a14dd143306a8ee1c2241320d29d5
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
cpufreq: ondemand: 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>
mmc: msm_sdcc: fix race conditions in runtime PM

What is the race condition? (NOTE: RPM stands for Runtime Power Management)

1. SDCC is in RPM_SUSPENEDED state and SDCC platform suspend gets
   triggered and then system goes into suspend.
2. During platform resume, SDCC platform resume is triggered
   which blindly sets the pending_resume flag in SDCC host structure.
3. If new MMC transfer request comes then MMC block driver calls
   mmc_claim_host() which internally calls msmsdcc_enable().
4. msmsdcc_enable() checks for following 3 conditions to be true:
	1. host->sdcc_suspended == true
	2. host->pending_resume == true
	3. pm_runtime_suspended() == false
   But as SDCC state is RPM_SUSPENDED, 3rd condition is not be satisfied
   so msmsdcc_enable() don't clear the host->pending_resume flag and simply
   calls pm_runtime_get_sync() to resume the SDCC. Once SDCC is resumed,
   host->sdcc_suspended = false, runtime_status = RPM_ACTIVE but
   host->pending_resume is still set.
5. Now after RPM idle timeout, SDCC runtime suspend gets triggered which
   calls SDCC driver's runtime suspend callback (msmsdcc_runtime_suspend).
   Note that before executing the RPM suspend calllback, SDCC RPM status
   is set to RPM_SUSPENDING.
6. As SDCC driver's runtime suspend callback gets executed, it sets the
   host->sdcc_suspended to true. But now before the RPM framework
   sets the SDCC RPM status to RPM_SUSPENDED, on other active CPU core,
   new MMC transfer reques comes in which would first call msmsdcc_enable()
   and all of the 3 conditions below is true:
	1. host->sdcc_suspended == true
	2. host->pending_resume == true
	3. pm_runtime_suspended() == false (RPM status is RPM_SUSPENDING)

   As these conditions are satisfied, msmsdcc_enable() does not call
   pm_runtime_get_sync(), instead just calls pm_runtime_get_noresume() and
   msmsdcc_runtime_resume(). This means even after execution of
   msmsdcc_enable(), SDCC RPM status is either RPM_SUSPENDING or
   RPM_SUSPENDED.
7. RPM suspend framework on 1st core sets the SDCC RPM status to
   RPM_SUSPENDED once SDCC runtime suspend callback returns.
8. Now once MMC transfer request is completed on other core, it will call
   msmsdcc_disable(). This function calls pm_runtime_put_sync() which
   returns -EAGAIN error as RPM status is already RPM_SUSPENED.
   This error gets returned to MMC layer so MMC layer thinks that
   SDCC is still enabled and skips call to msmsdcc_enable() until
   msmsdcc_disable() succeeds.
8. Note when msmsdcc_disable() returned error, RPM usage_counter was set to
   0 so next call to msmsdcc_disable() decrements RPM usage_counter to -1
   (remember msmsdcc_enable() was skipped).
9. Now new MMC request comes in and it will first call msmsdcc_enable()
   which calls pm_runtime_get_sync() and it sets the usage_counter to 0
   and blindly resumes the SDCC as it was already suspended. After this
   RPM status will be RPM_ACTIVE.
10. Once MMC request is processed, it will call smsdcc_disable() which
    calls pm_runtime_put_sync() and it decrements RPM usage counter to -1
    and skips scheduling runtime suspend callback as RPM usage counter
    is not 0. RPM status remains in RPM_ACTIVE.
11. Now onwards for every new MMC transfer requests, 9 and 10 repeats and
    SDCC always stays in RPM_ACTIVE state forever.

How is this race condition fixed?

Above race is created because host->pending_resume is remaining sticky.
Following changes are done to ensure that pending_resume gets set and
cleared at appropriate places:
1. In SDCC platform resume callback, set the host->pending_resume flag
   only if RPM status is RPM_ACTIVE.
2. Clear the pending_resume flag once msmsdcc_runtime_resume() is
   completed.
3. In msmsdcc_enable() function, if pending_resume flag is set skip calling
   pm_runtime_get_sync() instead directly call msmsdcc_runtime_resume()
   because RPM status is RPM_ACTIVE.

In addition, this patch adds WARN() messages in case of failures in
msmsdcc_enable() and msmsdcc_disable() functions to capture more details
in error conditions.

CRs-Fixed: 373338
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
(cherry picked from commit 386ad800716b6660d40c677b57ee4bf8e4430329)

Change-Id: I2c3b61c1b153cfed6db8c90ae3f7334b8830b5f7
Signed-off-by: Sudhir Sharma <sudsha@codeaurora.org>
mmc: msm_sdcc: set IO_PAD_PWR_SWITCH bit based on IO voltage level

SDCC4 controller has IO_PAD_PWR_SWITCH control bit in MCI_CLK register.
Driver should set this bit to 1 if the IO voltage level is within
low voltage range (1.7v - 1.9v) else clear it.

But driver sets this bit to 1 only if the MMC core layer initiates
the voltage switch sequence. So if voltage switch sequence is not
initiated (which is the case with non UHS-I cards) then even if
the IO voltage level is within low voltage range, IO_PAD_PWR_SWITCH
bit remains cleared.

This change checks the IO voltage level and based on that sets the
IO_PAD_PWR_SWITCH bit.

CRs-Fixed: 386445
Change-Id: Id0648b0f87ea9bcc942e855e30da810e0fe5ebf5
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
(cherry picked from commit 341b9e7dbaf0a3caf6e41d37486e3bccc9795feb)
Revert "mmc: core: Add 1ms delay after sending CMD6 to MMC cards."

This reverts commit def5e24abe4787b22b22138623eeb495ef8fec0d.

Reverted commit was added 3 years back due to this reason:
Some eMMC cards (SanDisk iNand eMMC cards to be specific) needed
this additional delay of 1 ms after sending the switch command to
card. This is a result of some issue with the SanDisk cards itself
and apparently they were going to fix this in their ASIC within
year or so. And Since Sandisk is one of the big players in the
eMMC space, it was important that our software works fine with their
cards.

But now we don't see any need of this additional delay on any of the
latest eMMC chipsets. Even open source version of this file doesn't
have this delay.

Change-Id: Iad5baa897f8fc0a360a17944fb87eb8e21e9bc53
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
(cherry picked from commit 581dd72b2e965e88f8ad93531c03a0c799e6384a)
mmc: msm_sdcc: remove the check for dml busy

dml busy status is supposed to be checked for during bam-to-bam mode
and not in bam-to-system mode. So removing the check for dml busy status
since the driver does not support bam-to-bam mode.

Change-Id: I1496ac441d70dd5efc831768f5ed3bfa11a3f94c
Signed-off-by: Krishna Konda <kkonda@codeaurora.org>
(cherry picked from commit 7a05d53e4aec382db2ce646805f6a69756337fdc)
(cherry picked from commit d1a6364ccb9523aca0e5dd6359437bfc3dda51b2)
mmc: msm_sdcc: set DDR timing mode before setting the clock rate

Setting DDR timing mode in controller before setting the clock
rate will make sure that card don't see the double clock rate
even for very small amount duration. Some eMMC cards seems to lock
up if they see clock frequency > 52MHz.
(cherry picked from commit 2877d919135791d5223a9ba94b2cfc9ba50bc3df)
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>

Change-Id: I7a4ace461e2def6d53863db4b768ec7e497b3095
Signed-off-by: Neha Pandey <nehap@codeaurora.org>
mmc: msm_sdcc: Reset interrupt MASK register (MCI_MASK0) on powering off

In one corner case, the SD card is stuck in a bad state with its DAT0
line pulled low, and SDCC is waiting on the interrupt when the line
goes back high. But due its bad state eventually the SD card is removed
from the system.

Later during re-scanning of the devices, the SD card is power-cycled and
added to the system. But now the pending interrupts for SD card is
received as the interrupt MASK register (MCI_MASK0) was not cleared.

To prevent such cases reset the interrupt MASK register (MCI_MASK0) while
powering off to prevent any pending interrupts after power-cycle.
(cherry picked from commit a3f8f793b21782c79a9fcc5f7aa1cc27fcbf246e)
CRs-Fixed: 396706
Signed-off-by: Pratibhasagar V <pratibha@codeaurora.org>

Change-Id: Idfae18895abf47769328b0a768f83eba2ef573f7
Signed-off-by: Neha Pandey <nehap@codeaurora.org>
mmc: Revert BKOPs feature

A newer version of BKOps should be picked from the community.
Therefore the old support is reverted.
Revert the following commits:
9db69fca22bd2970f6b14b50cf8533a1edb64364
8ac659eb3d96e31b8bb6b8d09143ddd6eb83ae19
f886c80ee2f4c29aeaab2d76c9303c00263bb428

(cherry picked from commit 3402d2b725a5af16bc62a2e788913a46d3f7e54a)

Change-Id: I5df105753bef7ee10215526006187673b85bb0c1
Signed-off-by: Maya Erez <merez@codeaurora.org>
(cherry picked from commit b5763af04035cd5e3264225f40270d175985adc5)
mmc: support BKOPS feature for eMMC

Enable eMMC background operations (BKOPS) feature.

If URGENT_BKOPS is set after a response, note that BKOPS are required.
Immediately run BKOPS if required.  Read/write operations should be
requested during BKOPS(LEVEL-1), then issue HPI to interrupt the
ongoing BKOPS and service the foreground operation.
(This patch only controls the LEVEL2/3.)

When repeating the writing 1GB data, at a certain time, performance is
decreased.  At that time, card triggers the Level-3 or Level-2.  After
running bkops, performance is recovered.

Future considerations:
 * Check BKOPS_LEVEL=1 and start BKOPS in a preventive manner.
 * Interrupt ongoing BKOPS before powering off the card.
 * How do we get BKOPS_STATUS value (periodically send ext_csd command)?
 * If using periodic bkops, also consider runtime_pm control.

(cherry picked from commit 6807769f7bf68984a5aeda4b9b521f1167cbaf00)

[merez@codeaurora.org: core.c: release_host when stopping BKOPs for
non SDIO cards in suspend]
(cherry picked from commit c1a56a1247341d13af7c8f84d5ac1211a3c4b376)

Change-Id: I5ac2ac909222e2b4e94cd97ce7da79f4488f06f0
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
Reviewed-by: Maya Erez <merez@codeaurora.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Maya Erez <merez@codeaurora.org>
(cherry picked from commit 653abe2434532e4d2886d27dfdc3f42ae1c7ade1)
mmc: core: Add the ability to enable BKOPS

If the card and the host support BKOPS, and BKOPS is not enabled
yet, set the BKOPS_EN bit to enable BKOPS.
This bit is one time programmable.

(cherry picked from commit e966c1ca32d118b26ca6e26267f0c13c9c0e0052)

Change-Id: I2b97898857bed676021fe56a6f6e49762cf609fa
Signed-off-by: Maya Erez <merez@codeaurora.org>
(cherry picked from commit 5ebe331e59e9c30bffead8e3030e3581ee699895)
mmc: msm_sdcc: Enable eMMCv4.5 BKOPS support

Set MMC_CAP2_INIT_BKOPS. This will set the BKOPS_EN bit in the
ext_csd register. The BKOPS_EN bit is one time programmable.

(cherry picked from commit b7f382b25fbd363c43af2332b4ff490e13aab6e4)

Change-Id: Ie913561b2b82ff28366ffe564ffcafe8fc19a96a
Signed-off-by: Maya Erez <merez@codeaurora.org>
(cherry picked from commit 2d29e0d34e3304d976291d3ab29c7c893c12d740)
mmc: Revert all packing related patches

The version of packing support excepted by the linux community is
slightly different from the one that was merged. This revert is needed
in order to upload the latest version from the linux community.

This patch reverts the following commits:
1.mmc: card: Add eMMC4.5 write packed commands unit-tests
2.mmc: card: Fix packing control enabling algorithm
3.mmc: block: Add MMC write packing statistics
4.mmc: msm_sdcc: enable the write packing control
5.mmc: msm_sdcc: Enable write packing capability
6.mmc: block: Add write packing control
7.mmc: core: Support packed write command for eMMC4.5 device
8.mmc: core: Add packed command feature of eMMC4.5

(cherry picked from commit f94cf3da103b344b13fa4d6665fd21dad1b95ead)

Change-Id: I2efc6dc8d8f6d5cc7e9efa99ec74914ffff96fcd
  commit:  9b54d88c6a11ebfe069b7fdebcb521da21754c3f
  commit: e2ecb58a6c5011549aac3e86fb1c13e7b7c65104
  commit: e544d700e2dac1584a8172c4dc347d81ede203bd
  commit: 8afe8d2a98a1bbf3804162ff5c95a56226935f5a
  commit: 25e2261a556c4393f79d58bce814bb3df34b9549
  commit: 63c61d6d8b8f37c71b4162b3affffdf72ac06811
  commit: 968c774ea6466fa7adbf2eac333220132acda306
  commit: 516994eee39282b8648b509e449ff83b49833209.
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
(cherry picked from commit 31fe84d6edae65f9df5663538e528697897be86e)

Signed-off-by: Maya Erez <merez@codeaurora.org>
mmc: msm_sdcc: Enable write packing capability

The write packing allows sending several requests in a single command
to the card and increases the eMMC performance in sequential write
operations.

(cherry picked from commit 34a444f2041763d617391be44f4a9ac1b7d6eab7)

Change-Id: I45978c8130d3898b21e36309696647c380521a87
Signed-off-by: Maya Erez <merez@codeaurora.org>
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
(cherry picked from commit 94a78f62307a53e9051e6f3970e1a937361078ba)
Signed-off-by: Maya Erez <merez@codeaurora.org>