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.

Signed-off-by: Patrick Cain <pcain@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
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.

Signed-off-by: Rohit Gupta <rohgup@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
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.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
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.

Signed-off-by: Vikram Mulukutla <markivx@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
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.

Signed-off-by: Patrick Cain <pcain@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
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.

Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Revert "iommu: msm: Add timeouts for some operations"

This reverts commit e77f861a361431d540284f044142ef452dc45ad9.

Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
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.

Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
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.

Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
hh: Enable IOMMU VBIF check

Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
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

Signed-off-by: Mahesh Sivasubramanian <msivasub@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
cma: Make locking finer grained

CMA locking is currently very coarse. The cma_mutex protects both
the bitmap and avoids concurrency with alloc_contig_range. There
are several situations which may result in a deadlock on the CMA
mutex currently, mostly involving AB/BA situations with alloc and
free. Fix this issue by protecting the bitmap with a mutex per CMA
region and use the existing mutex for protecting against concurrency
with alloc_contig_range.

Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
ion: retry during race with shrinking/allocating

There exists a race between shrinking/allocating

Thread 1:                           Thread:2
mutex_lock(&sheap->alloc_lock)
ion_secure_cma_add_to_pool()
mutex_lock(&sheap->chunk_lock)
chunk->cnt = 0
mutex_unlock(&sheap->chunk_lock)
                                    ion_secure_cma_shrinker
                                    mutex_lock(&sheap->chunk_lock)
                                    __ion_secure_cma_shrink_pool
                                    chunk->cnt == 0 for the
                                       just allocated chunk
                                    ion_secure_cma-free_chunk
ion_secure_cma_alloc_from_pool
no memory to allocate!

If this race happens, just retry adding memory to the pool instead
of BUGing out the system.

Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
msm: lpm_levels: Fix incorrect computation of next wakeup time

The next event timer wakeup was incorrectly computed when the hard timer
event doesn't exist. Fix by ensuring the next wakeup is computed only
when a timer event is valid

Signed-off-by: Mahesh Sivasubramanian <msivasub@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
cpufreq: Tune intelliactive governor

* Match frequencies with that we are using for interactive

Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
ARM: dts: msm8974: Further reduce retention voltages

* Based on @faux123 's commit: https://github.com/faux123/Nexus_5/commit/058
* Reducing retention voltage for non-boot CPUs

Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
defconfig: Update

Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>