cpufreq: ondemand: Remove unnecessary synchronization attempt

Commit 1ce28d6b (ondemand: updated tune for hardware coordination)
brings in an attempt to synchronize expiry of per-cpu ondemand timer
at same time across all online cpus. This is meant to help systems
where "multiple cores share P-state via Hardware Coordination".

Synchronization is achieved by having timers expire when jiffy value
would be a perfect multiple of sampling window size. While such
synchronozation attemps are unnecessary on systems where cores don't
share P-states, it can hurt on power as cpus can now work off shorter
sampling windows (when percentage utilization over short window can be
observed to be high, causing frequency to be boosted).

Remove this unnecessary attempt to synchronize expiry of ondemand
timer across online cpus. A more acceptable solution could be to have
low-level architecture specific cpufreq driver indicate the need for
synchronization.

Change-Id: I6cb1cf3472ca106f029dc01248e0df7cfbb495b8
Signed-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>
cpufreq: interactive: delete timers for GOV_START

Make sure that timers cpu_timer and cpu_slack_timer
deactivated before addition of new.

Change-Id: If31c4049606871df6f00efdc24b1d713c86a6f69
Signed-off-by: Shridhar Rasal <srasal@nvidia.com>
Signed-off-by: Bharat Nihalani <bnihalani@nvidia.com>
Git-commit: b430123367e78a6557bac3cf1558bcb85193fb12
Git-repo: https://android.googlesource.com/kernel/common/
[mattw@codeaurora.org: resolved trivial context conflict]
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
cpufreq: Sync on thread migration optimizations

When threads migrate between CPUs the destination CPU will temporarily
have a boosted frequency and the source CPU will have a residual higher
frequency even though the load could have just been reduced. To avoid
leaving CPUs at a high frequencies notify the source CPU after a thread
migration and make the interactive governor's timer reschedule
conditionally.

Change-Id: Id55055f2a116ca7ffd2a34dc3d0ec519c888a111
Signed-off-by: Patrick Cain <pcain@codeaurora.org>
cpufreq: interactive: Don't reset sampling down factor at max freq

A previous patch sets the min_sample_time to zero if the cpufreq
min/max limits have changed which would bring down the frequency
in the next sample even if min_sample_time doesnt allow it to do so.
This could severly affect benchmarks if this is applied to max
frequencies as min_sample_time for max frequencies is set to
sampling_down_factor.
This patch resets the limits_changed flag for cases where timer fires
while running at max frequencies so that sampling_down_factor is
still applicable as before.

Change-Id: I397133cb15eea4ab999d0f69617b4922438c6e11
Signed-off-by: Rohit Gupta <rohgup@codeaurora.org>
cpufreq: interactive: Remove unnecessary cpu_online() check

Cpufreq no longer calls governor callback for offlined cpus. i.e. All
policy->cpus are guaranteed to be online. Hence we don't need explicit check to
see if cpu is online or not.

Change-Id: I9ad85ea4addd5b4a40952e59ed730dd15e328690
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
msm: cpufreq: Correct synchronous cpu logic

Fix an incorrect patch conflict resolution which results in failing to
initialize the cpufreq policy correctly when using an old acpuclock driver
version.

Change-Id: If8743a2608e720258ebc710718c3041144c00f10
CRs-fixed: 612226
Signed-off-by: Patrick Daly <pdaly@codeaurora.org>
msm: cpufreq: Fix msm_cpufreq_get_freq() for sync CPUs

When CPUs are in sync, only CPU0 has a non-NULL cpu_clk. clk_get_rate()
on other cpu_clk will return 0. msm_cpufreq_get_freq() is used in multiple
places in cpufreq framework to determine current hardware frequency.

Fix msm_cpufreq_get_freq() to return the right hardware frequency for
systems with synchronous CPUs.

Change-Id: I6a880764ad51fa9a257a328798b38d574750686a
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
qcom-cpufreq: Move the enabling of the CPU/L2 clocks to CPU_STARTING

It is a requirement of PLLs in MSM SoCs that the PLL power
supplies be enabled while the PLL is running. If the PLL is
locked and outputs enabled, turning off the regulator(s)
supplying the PLL will cause the PLL to enter an unpredictable
state.

Now in the CPU_UP_PREPARE notifier, the CPU clocks are prepared
and enabled, causing the source HFPLLs to also turn on. Note
that the CPU isn't clocked yet. It is possible that execution is
pre-empted and the CPU running the notifier enters power
collapse. If all other CPUs also enter power collapse, then it
is possible for an RPM notification to go out, allowing the RPM
to transition the Apps processor to its sleep set. This can
result in the HFPLL supplies being turned off while the HFPLL is
running, violating the requirement mentioned above. Once the CPU
is unclamped, the CPU is effectively unclocked, due to the HFPLL
being in an unknown state.

There is a check that is enabled in the PM code's CPU_UP_PREPARE
notifier callback. This check ensures that the problematic RPM
notification cannot occur until the core that is being brought
online also enters power collapse. However, there is no ordering
guarantee between that PM's hotplug notifier callback's execution
and the cpufreq hotplug notifier callback's execution. This
ordering depends on program link order, which is unreliable.

It is necessary to ensure that once the HFPLL is enabled, the
RPM cannot transition apps to its sleep set. Move the enabling
of the CPU clocks to the CPU_STARTING notifier, which runs on
the CPU bring brought online. The CPU_STARTING notifier is
guaranteed to run after the CPU_UP_PREPARE notifier, which
implies that the aforementioned do-not-notify-rpm check is
executed *before* the HFPLL is enabled. Therefore even if all
cores enter power collapse after the HFPLL is enabled, the
HFPLL supplies are guaranteed to stay on, or the CPU clock
is switched to the safe source and the HFPLL is turned off.

CRs-Fixed: 622738
Change-Id: I136841405806c07e755919859e649ded0c719abb
Signed-off-by: Vikram Mulukutla <markivx@codeaurora.org>
cpufreq: cpu-boost: Re-issue boosts above minimum frequency

Frequency boosts where the source CPU frequency is greater than CPU's
minimum frequency should always go through regardless of the destination
CPU's current frequency. This fixes a performance issue where the governor
lowers the CPU frequency shortly after a thread is migrated to it because
the boost wasn't re-issued.

Change-Id: I449545a688d84b0a6e834f5a51dcb499caa84d29
Signed-off-by: Patrick Cain <pcain@codeaurora.org>
Revert dubious scheduler changes.

 * Rolled this series back on other devices as well. It's causing bad
   jank all over the system under a lot of use cases.

Revert "sched: reinitialize rq->next_balance when a CPU is hot-added"

This reverts commit 7c588520b259bf0a342058aa4a9e5ea677522a0d.

Revert "nohz: stat: Fix CPU idle time accounting"

This reverts commit 9446ae3986469a19a603344862e856d54f6df15b.

Revert "sched: remove redundant update_runtime notifier"

This reverts commit 1eb858976a30964ee1812f34f8a05056814ea8e9.

Revert "sched,rt: disable rt_runtime borrowing by default"

This reverts commit a731e214fe6606896de2b50a629bedbdbd95ced7.

Revert "sched/rt: Remove redundant nr_cpus_allowed test"

This reverts commit e169d922cc1fa6026225f9abc71ea28facafd43a.

Revert "sched: Micro-optimize the smart wake-affine logic"

This reverts commit 3bd0f8f8c045c77ca1d46a95ae09ab08c5d52c5d.

Revert "sched: Implement smarter wake-affine logic"

This reverts commit 8ea57b5895029c0694e8cb53295ce2cf735e9505.

Revert "sched: Reduce overestimating rq->avg_idle"

This reverts commit b49d8687515095bdf5089014c2c023d0e61de0cc.

Revert "sched: scale the busy and this queue's per-task load before compare"

This reverts commit a4d496cb8d418891f12cca0e5a3bd64dc2b83ea9.

Revert "sched: reduce calculation effort in fix_small_imbalance"

This reverts commit 65d048b5ef51f2104d3a26fb3e1fddfa8d401090.

Revert "mutex: back out architecture specific check for negative mutex count"

This reverts commit 2f983cc28c06648cc6a50b28a85b3008b51ec850.

Revert "mutex: Queue mutex spinners with MCS lock to reduce cacheline contention"

This reverts commit f6ab92b597a5d1cc6e4ffe82a787cd868140bc09.

Revert "mutex: Make more scalable by doing less atomic operations"

This reverts commit f425908d01a43e0e63e42d51b50c7b9b028e9702.

Change-Id: I7fcb7b2a7bb5657bf70a2189b2d04a5289987106
iommu: msm: Add base physical address to drvdata structure

Add the physical address value to the iommu drvdata structure. This
address is needed for debugging purposes when we get iommu page
faults and during iommu halt and tlb sync issues.

Change-Id: I2d4f36cdfe8a3da772839cb07cd186820f2e1f52
Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
Revert "msm: iommu: remove tlb_invalidate from the map calls"

This might cause TLB invalidate to hang on unmap calls.

This reverts commit 8da8a5a49ce5dcbb5b5f97da8d66b34129562e80.

Change-Id: Ibbe373d448a3bea5e75bc45dd0a16e79f57c092b
Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
Revert "iommu: msm: Add timeouts for some operations"

This reverts commit e77f861a361431d540284f044142ef452dc45ad9.
iommu: msm: Do not sleep for 10 ms when TLB sync does not complete

TLB sync might take longer than expected to complete and we wait for 10 ms
to recheck. This is causing jitter in some applications. Instead of waiting
too long to check whether TLB sync has completed we use function
readl_tight_poll_timeout to quickly poll the status without incurring sleep
delay.

We also ensure that if we do eventually time out on the TLB sync or iommu
halt we cause a crash to indicate that something has gone wrong.

CRs-fixed: 608971
Change-Id: I6b3e5155ab7aafa80432f95554d25cf0e2b753f9
Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
iommu: msm: Check VBIF state during IOMMU access timeout

Check whether halting the VBIF XIN when the TLB sync or IOMMU halt
times out clears the issue indicating an issue with the master not clearing
the VBIF FIFO.

Change-Id: I552f72db17e31a174ab2725bbecbf4ad98a9d378
Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
hh: Enable IOMMU VBIF check

Change-Id: Ifba3f6529d4aa01506bf9bf8151d7b474294ee50
msm: msm_bus: Introduce multi level BKE limiting.

Introduce multi level BKE throttling for BIMC masters. By specifying an
array of thresholds and limiting bandwidth values, multiple levels of
master throttling can be achieved.

Change-Id: Ic3b483d3e987266e8f37e66dff8bedd49ddd1d4d
Signed-off-by: Girish Mahadevan <girishm@codeaurora.org>
Signed-off-by: Akhila Musunuri <makhila@codeaurora.org>
ARM: dts: Modify BKE limiting for Krait master

Modify the BKE limiting properties for Krait master by setting up 2
levels of threshold checks and limiting bandwidth values to be applied.
These levels of throttling are needed in certain concurrency usecases to
protect real time masters from surges in bus usage from some APSS masters.

Change-Id: I04d086e10df27d0f7cc1a234fe9eb36a9ea73e65
Signed-off-by: Girish Mahadevan <girishm@codeaurora.org>
Signed-off-by: Akhila Musunuri <makhila@codeaurora.org>
arm: arch_timer: set memory mapped timer interrupt as IRQF_TIMER

The memory mapped timer is used as a broadcast timer to wake the core for
timer interrupts when the arch timer might not be functional. When interrupt
is not marked as IRQF_NO_SUSPEND, the interrupt gets disabled during the
suspend_device_irqs() callback in the suspend path. If a core were to enter a
idle low power mode which relies on broadcast timer to process the interrupt,
the core is never woken up for timer interrupts.

Mark the interrupt with IRQF_TIMER which marks this interrupt as a timer
interrupt and also marks it as IRQF_NO_SUSPEND

CRs-fixed: 636712
Change-Id: I0484e92a9d05f66a0c5b3c00c584a3dd3fe6ae85
Signed-off-by: Mahesh Sivasubramanian <msivasub@codeaurora.org>
rtc: alarm: Proper handling of spinlock

In alarm_shutdown hook, taking interruptible mutex
lock in interrupt disabled context. This patch fixes
alarm_shutdown function to call rtc_read_time and
rtc_set_alarm APIs in interrupt enabled context.

Change-Id: I9392d8908c19365993dccc22504f4b6f83ae8f72
CRs-Fixed: 619657
Signed-off-by: Mohit Aggarwal <maggarwa@codeaurora.org>