bdi: use deferable timer for sync_supers task

sync_supers task currently wakes up periodically for superblock
writeback. This hurts power on battery driven devices. This patch
turns this housekeeping timer into a deferable timer so that it
does not fire when system is really idle.

CRs-Fixed: 353700
Signed-off-by: Yong Wang <yong.y.wang@intel.com>
Signed-off-by: Xia Wu <xia.wu@intel.com>
Signed-off-by: Krishna Vanka <kvanka@codeaurora.org>
(cherry picked from commit f398f30d1f34632d3c96758b5b19e65b056af072)

Change-Id: I6ec6310d66c0d014adf0f41e75cd4c48c233f83d
Signed-off-by: Sridhar Gujje <sgujje@codeaurora.org>
sched/nohz: Correctly initialize 'next_balance' in 'nohz' idle balancer

The 'next_balance' field of 'nohz' idle balancer must be initialized
to jiffies. Since jiffies is initialized to negative 300 seconds the
'nohz' idle balancer does not run for the first 300s (5mins) after
bootup. If no new processes are spawed or no idle cycles happen, the
load on the cpus will remain unbalanced for that duration.

Signed-off-by: Diwakar Tundlam <dtundlam@nvidia.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1DD7BFEDD3147247B1355BEFEFE4665237994F30EF@HQMAIL04.nvidia.com
Signed-off-by: Ingo Molnar <mingo@elte.hu>

[xqi@codeaurora.org merge into different file location in 3.0]
Change-Id: I42c41210babb0881150d28d11c2d3fce24fe3a9f
Signed-off-by: Xin Qi <xqi@codeaurora.org>
sched/nohz: Fix logic in nohz_kick_needed

Update the logic so that as long as rq->nr_running is greater than 1,
nohz_kick will be needed, regardless of whether the current CPU has
successfully competed for the first or second cpu spot

Previous logic has the corner case that if current CPU has r_running more than
1, and two other CPUs alreay hold first and econd cpu spot, but they don't
meeting kicking criterial (first cpu has nr_running 1, and second cpu doesn't
have any load), then nohz_kick will not be set correctly.

Change-Id: I30790f22df0a2e90899daa44c67757284dcca25d
Signed-off-by: Xin Qi <xqi@codeaurora.org>
sched/nohz: Fix logic in run_rebalance_domains

If triggered by nohz_balancer_kick, idle_at_tick is not updated
accordingly.  Update myself at this moment right before it is used

Change-Id: I20dd4314159e70f955ffe482160c8867c65c261e
Signed-off-by: Xin Qi <xqi@codeaurora.org>
sched/nohz: Fix logic in trigger_load_balance

Whether we need to kick nohz doesn't depend on current rq->next_balance,
meaning it doesn't depend on the check of previous if condition.

Change-Id: I566011d6341fa7a9a700c834f77e129043eaba11
Signed-off-by: Xin Qi <xqi@codeaurora.org>
msm: idle-v7.S: Warmboot support for NR_CPUS >= 2

The change supports save/restore of processor state during warmboot when
the number of cores is greater than 2. The current version supports two
cores only.

Change-Id: Icd23f10cde00a5dbe0abc1a76f1555f8834053a3
Signed-off-by: Mahesh Sivasubramanian <msivasub@codeaurora.org>
msm: idle-v7: Power collapse Krait with caches enabled

The SCTLR[C/I] bits do not need to be cleared when entering
power collapse on Krait CPUs.

Change-Id: Ic33b227fe55a87e10aab46e6a30f44cc400ccfbb
Signed-off-by: Stepan Moskovchenko <stepanm@codeaurora.org>
msm: idle-v7: Remove redundant cache clean

Cleaning the register save area is not necessary if we are
already cleaning the entire cache. Eliminate the redundant
cleaning operation to reduce power collapse latency.

Change-Id: I3651083f147874fd6003cfe12b07861689ca77cc
Signed-off-by: Stepan Moskovchenko <stepanm@codeaurora.org>
msm: idle-v7 : Restore context for NR_CPUS >= 2 when PC fails

When there is a pending interrupt and the core executes WFI
instruction, the SPM would not trigger its state machine and would
bail out. The instructions after the WFI instruction will be executed.
The context calculation need to take care of getting the right context
to restore.

Change-Id: Icda4abe68503250f27b8c9b89891318beab86a7b
Signed-off-by: Praveen Chidambaram <pchidamb@codeaurora.org>
msm: idle-v7: do not clean and invalidate after warm boot

The boot chain will already have invalidated any caches which
contain invalid data due to powering the caches on, so it is not
necessary to do that operation here. This call is also incorrect
because it is being done after caches are already enabled.

Change-Id: I1402f08712f45cb4598bcbc470b89637c1952056
Signed-off-by: Steve Muckle <smuckle@codeaurora.org>
msm: pm: save registers to noncached area before pc

The power collapse path is simplified if a noncached area is
used for the purpose of saving register state prior to power
collapsing. This is especially beneficial in the case of targets
with an outer cache, where the process of cleaning the register
state would require complex operations.

Change-Id: I9edac28e4091548e2843fc87c89e3451df2b6ae9
Signed-off-by: Steve Muckle <smuckle@codeaurora.org>
msm: pm: clean msm_pm_pc_pgd in the cache after writing

Since a CPU will read the msm_pm_pc_pgd value as it comes
up from power collapse when caches are disabled, it needs
to be guaranteed that the value has been written to memory
before any CPU power collapses.

Change-Id: I7f6358a001255f9bac99a6378532c96fd460f82b
Signed-off-by: Steve Muckle <smuckle@codeaurora.org>
msm: 8960: Set last sleep mode variable for WFI

Set the last sleep mode variable correctly when
entering WFI sleep mode.

Change-Id: I68bbb09b46fe5d7229fbbc67f636294f0d9e92d6
Signed-off-by: Girish Mahadevan <girishm@codeaurora.org>
gpu: ion: Reference count protect/unprotect calls

Reference count the calls to ion_{un}secure_heap. The secure SCM
call will only be made when the count goes from 0 -> 1 and the
unsecure call will only be made when the count goes from 1 -> 0.

Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
(cherry picked from commit f68983eaa0b7b9eb2bb35937e799a43fab5442d5)

Change-Id: I8c24f90ce71481c6b0c5079a3c02c44a120bb376
Signed-off-by: Ramakrishna Prasad N <crpn@codeaurora.org>
msm: gpio-v2: Fix spurious interrupts when gpio-irq is unmasked

To unmask a gpio interrupt, the gpio driver sets the
INTR_RAW_STATUS_EN and INTR_ENABLE bits in the INTR_CFG register.
As soon as the INTR_RAW_STATUS_EN is set, the INTR_STATUS is updated
and this causes a spurious interrupt when the irq is enabled.
This is noticed frequently when the gpio is pulled high and requests
a rising edge interrupt or pulled low and is requesting a falling edge
interrupt.
Due the internal circuit design of the TLMM IRQ block, the above method
causes a spurious interrupt when the irq was initialized.
Hence, to avoid this behavior we set the INTR_RAW_STATUS_EN, clear the
INTR_STATUS only once during setup. Every mask and unmask only toggles
the INTR_ENABLE bit.

CRs-Fixed: 346861
Change-Id: Id8353286181fe38a419bd7421518b33f2f8b26aa
Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
Signed-off-by: Taniya Das <tdas@codeaurora.org>
msm: gpio-v2: Re-arrange the write to RAW_STATUS_EN

Move enabling the RAW_STATUS_EN at the very beginning.
Hardware team clarified that it is better to write to
RAW_STATUS_EN before writing to any other INTR_CFG bits
in order to prevent spurious interrupts.
Removing writing to the GPIO_INTR_CFG_SU register
during every mask/unmask as it could cause spurious
interrupts as well.

Change-Id: Ifbd991364216ef5f163e5211bc35f7f145c75916
CRs-Fixed: 346861
Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
msm: gpio-v2: Clear the interrupt status before unmasking

After the change to keep the RAW_STATUS_EN always on, the
interrupt status bit was latched and could be set during
other (non-interrupt) activity on the GPIO line. This would
end up triggering the interrupt as soon as it was unmasked.
Hence, clear the interrupt status before unmasking the gpio
interrupt.
This keeps the behavior and expectations same as when the
RAW_STATUS_EN was toggled and it prevented the interrupt
status from being updated while the interrupt was masked.

Change-Id: I2bbfa36e4ec0f4a961f05047f4061d7d8fc9fd2f
CRs-Fixed: 346861
Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
thermal: Don't limit CPU frequency after msm_thermal is disabled

There may be an outstanding task to check for threshold crossing
when msm_thermal is disabled and CPU is restored to maximum
frequency. This task can get scheduled after the maximum frequency
is restored, and result in another mitigation that pins CPU
frequencies to 918mHz. This happens in the case that the final
temperature was still above the max temperature threshold.
This patch ensures any outstanding tasks are cancelled and flushed
before finally restoring the CPU frequencies.

CRs-fixed: 351614
Change-Id: Ifce00b379989b78856803ac09c7403207f5c998b
Signed-off-by: Eugene Seah <eseah@codeaurora.org>
msm: thermal: Simplify kernel thermal safeguard mechanism

Using CPUFreq policy objects and setting the max frequency limit by
overriding the policy->max node, leads to race/overwrite conditions with
an user trying to use the scaling_max_frequency node.

The thermal limits are directly communicated to the 'msm' cpufreq driver
and use the cpufreq_update_policy() to ensure that the frequency is
limited as per the thermal safeguard requirements.

CRs-fixed: 370343
Signed-off-by: Praveen Chidambaram <pchidamb@codeaurora.org>
(cherry picked from commit 9181436c8d688480ded367557b4b9b012b1881b2)

Change-Id: I5c4ceaac00c6dcd91eb207c555519f9c5fd08d9b
Signed-off-by: Shruthi Krishna <skrish@codeaurora.org>
msm: cpufreq: Add API to allow limiting of min and max cpu frequencies

CPUFreq provides scaling sysfs nodes to set min and max frequencies, but
there are times when the operating range has to be controlled
irrespective of the scaling limits, to ensure the thermal stability of
the device.

The API allows kernel thermal safeguards to pitch in and limit the
frequencies.

Signed-off-by: Praveen Chidambaram <pchidamb@codeaurora.org>
(cherry picked from commit 696a561c5bbc4733476db16be6f05fd92dee9a71)

Change-Id: I7faa1205948b81a23d24a3b29bdedc98a07a5861
Signed-off-by: Shruthi Krishna <skrish@codeaurora.org>