msm: mdss: Clear the previous state of pipe during SOLID_FILL

Clear the previous state of pipe when it is being used in SOLID_FILL
operation to prevent wrong register configuration. For ex: Use case
when DMA pipe was used in BLOCK mode in previous frame, then it is
being used in LINE mode for SOLID_FILL operation in current frame.

CRs-Fixed: 655993
Change-Id: I0ed257276428b96c10a92457a16df4dfdc42c1f8
Signed-off-by: Sushil Chauhan <sushilchauhan@codeaurora.org>
Signed-off-by: MassStash <MassStash@gmail.com>
msm: mdss: refactor pipe retrieval and ref count logic

Allow only retrieval of pipes that are on particular framebuffer device
used list. This ensures that pipe is not modified from a different fb
device node and cause potential issues.

Also, modify the ref count logic to use kref and ensure pipe is freed
only while holding mutex in case there could be race condition that
pipe is allocated while being freed.

Change-Id: I626323b5df981a7ed1e03196126cd4376b5ba6a6
Signed-off-by: Adrian Salido-Moreno <adrianm@codeaurora.org>
Signed-off-by: Anusha Koduru <kanusha@codeaurora.org>
Signed-off-by: MassStash <MassStash@gmail.com>
msm: mdss: refactor pipe retrieval and ref count logic (fix)

Allow only retrieval of pipes that are on particular framebuffer device
used list. This ensures that pipe is not modified from a different fb
device node and cause potential issues.

Also, modify the ref count logic to use kref and ensure pipe is freed
only while holding mutex in case there could be race condition that
pipe is allocated while being freed.

cyanogen: this patch was not applied completely

Change-Id: I626323b5df981a7ed1e03196126cd4376b5ba6a6
Signed-off-by: Adrian Salido-Moreno <adrianm@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: MassStash <MassStash@gmail.com>
msm: rq_stats: Calculate load based on current freq limit

Prior to this patch, load has been calculated based on an
initial value of policy.cpuinfo.max_freq. This value may
change for several reasons: userspace settings or thermal
throttling (hello hammerhead!). This results in unreliable
calculations that confuse mpdecision which accesses
/sys/devices/system/cpu/cpu0/rq-stats/* for stats info.
Consider current policy.max to fix this behaviour.

Change-Id: Iae1f2fc7f4aa470f7e80371c1ebcf7be423f51ca

Signed-off-by: MassStash <MassStash@gmail.com>
cpufreq: interactive: restructure CPUFREQ_GOV_LIMITS

The cpufreq_interactive_timer gets cancelled and rescheduled
whenever the cpufreq_policy is changed. When the cpufreq policy is
changed at a rate faster than the sampling_rate of the interactive
governor, then the governor misses to change the target frequency
for long duration. The patch removes the need of cancelling the
timers when policy->min is changed.

Signed-off-by: Badhri Jagan Sridharan <Badhri@google.com>
Change-Id: I7862f1c8022a3b98a890e7537f93d02010e86764
Signed-off-by: MassStash <MassStash@gmail.com>
cpufreq: interactive: turn boost_pulse off on boost off

Change-Id: I36fe217fa047d68ea90e78b12c7db4537ea8010b
Signed-off-by: Ruchi Kandoi <kandoiruchi@google.com>
Signed-off-by: MassStash <MassStash@gmail.com>
tick: Upstream fixes

 * Addresses the issue of timers being scheduled on offline CPUs.

tick: Don't invoke tick_nohz_stop_sched_tick() if the cpu is offline

commit 5b39939a4 (nohz: Move ts->idle_calls incrementation into strict
idle logic) moved code out of tick_nohz_stop_sched_tick() and missed
to bail out when the cpu is offline. That's causing subsequent
failures as an offline CPU is supposed to die and not to fiddle with
nohz magic.

Return false in can_stop_idle_tick() if the cpu is offline.

Reported-and-tested-by: Jiri Kosina <jkosina@suse.cz>
Reported-and-tested-by: Prarit Bhargava <prarit@redhat.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Tony Luck <tony.luck@intel.com>
Cc: x86@kernel.org
Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1305132138160.2863@ionos
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

timers: Consolidate base->next_timer update

Another bunch of mindlessly copied code. All callers of
internal_add_timer() except the recascading code updates
base->next_timer.

Move this into internal_add_timer() and let the cascading code call
__internal_add_timer().

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Gilad Ben-Yossef <gilad@benyossef.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Link: http://lkml.kernel.org/r/20120525214819.189946224@linutronix.de

timers: Create detach_if_pending() and use it

Most callers of detach_timer() have the same pattern around
them. Check whether the timer is pending and eventually updating
base->next_timer.

Create detach_if_pending() and replace the duplicated code.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Gilad Ben-Yossef <gilad@benyossef.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Link: http://lkml.kernel.org/r/20120525214819.131246037@linutronix.de

timers: Add accounting of non deferrable timers

The code in get_next_timer_interrupt() is suboptimal as it has to run
through the cascade to find the next expiring timer. On a completely
idle core we should only do that when there is an active timer
enqueued and base->next_timer does not give us a fast answer.

Add accounting of the active timers to the now consolidated
attach/detach code. I deliberately avoided sanity checks because the
code is fully symetric and any fiddling with timers w/o using the API
functions will lead to cute explosions anyway. ulong is big enough
even on 32bit and if we really run into the situation to have more
than 1<<32 timers enqueued there, then we are definitely not in a
state to go idle and run through that code.

This allows us to fix another shortcoming of get_next_timer_interrupt().

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Gilad Ben-Yossef <gilad@benyossef.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Link: http://lkml.kernel.org/r/20120525214819.236377028@linutronix.de

timers: Improve get_next_timer_interrupt()

Gilad reported at

 http://lkml.kernel.org/r/1336056962-10465-2-git-send-email-gilad@benyossef.com

"Current timer code fails to correctly return a value meaning that
 there is no future timer event, with the result that the timer keeps
 getting re-armed in HZ one shot mode even when we could turn it off,
 generating unneeded interrupts.

 What is happening is that when __next_timer_interrupt() wishes
 to return a value that signifies "there is no future timer
 event", it returns (base->timer_jiffies + NEXT_TIMER_MAX_DELTA).

 However, the code in tick_nohz_stop_sched_tick(), which called
 __next_timer_interrupt() via get_next_timer_interrupt(),
 compares the return value to (last_jiffies + NEXT_TIMER_MAX_DELTA)
 to see if the timer needs to be re-armed.

 base->timer_jiffies != last_jiffies and so tick_nohz_stop_sched_tick()
 interperts the return value as indication that there is a distant
 future event 12 days from now and programs the timer to fire next
 after KTIME_MAX nsecs instead of avoiding to arm it. This ends up
 causing a needless interrupt once every KTIME_MAX nsecs."

Fix this by using the new active timer accounting. This avoids scans
when no active timer is enqueued completely, so we don't have to rely
on base->timer_next and base->timer_jiffies anymore.

Change-Id: I874ee5e5f837a228cebf5e6a084baf520d33cd0f
Reported-by: Gilad Ben-Yossef <gilad@benyossef.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Link: http://lkml.kernel.org/r/20120525214819.317535385@linutronix.de
Signed-off-by: MassStash <MassStash@gmail.com>
timer: Generalize timer->base flags handling

To prepare for addition of another flag, generalize timer->base flags
handling.

* Rename from TBASE_*_FLAG to TIMER_* and make them LU constants.

* Define and use TIMER_FLAG_MASK for flags masking so that multiple
  flags can be handled correctly.

* Don't dereference timer->base directly even if
  !tbase_get_deferrable().  All two such places are already passed in
  @base, so use it instead.

* Make sure tvec_base's alignment is large enough for timer->base
  flags using BUILD_BUG_ON().

Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: torvalds@linux-foundation.org
Cc: peterz@infradead.org
Link: http://lkml.kernel.org/r/1344449428-24962-2-git-send-email-tj@kernel.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

Change-Id: I371295186ad8c08d243f82ec68f92344317f3e6a
Signed-off-by: MassStash <MassStash@gmail.com>
mdss: Dynamic timeout calculation for cmd stop

Time out condition was hard coded to 60 fps. If dynamic fps
feature was used, an invalid timeout might occur.

Change-Id: I0abe52416c10ef4ae0af6f541d22c66f6c8a6b5e
Signed-off-by: Terence Hampson <thampson@codeaurora.org>
Signed-off-by: MassStash <MassStash@gmail.com>
ARM: dts: msm: Add support for second qcrypto device for 8974

Add entry for a second qcrypto instance that uses a different
pipe pair for data transfer to/from CE hardware. This will allow
clients to use different PIPE key register set intended for a
different use case.

Change-Id: Ibdf5ae10de63f1a26ce37ab9b74e4a60346cc105
Signed-off-by: Mona Hossain <mhossain@codeaurora.org>
Signed-off-by: Zhen Kong <zkong@codeaurora.org>
Signed-off-by: MassStash <MassStash@gmail.com>
clock: msm: Add clk support for second qcrypto device

Add clock entry for a second qcrypto instance for 8974.

Change-Id: I6e4c6e32e62c5cf26992c7d0dc8b27b188c2b15c
Signed-off-by: Mona Hossain <mhossain@codeaurora.org>
Signed-off-by: MassStash <MassStash@gmail.com>
ARM: add cpufreq transiton notifier to adjust loops_per_jiffy for smp

If CONFIG_SMP, cpufreq skips loops_per_jiffy update, because different
arch has different per-cpu loops_per_jiffy definition.

Change-Id: I3bfdf800784c9c494f873de096e3a1972f14f358
Signed-off-by: Richard Zhao <richard.zhao@linaro.org>
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: MassStash <MassStash@gmail.com>
ARM: 7653/2: do not scale loops_per_jiffy when using a constant delay clock

When udelay() is implemented using an architected timer, it is wrong
to scale loops_per_jiffy when changing the CPU clock frequency since
the timer clock remains constant.

The lpj should probably become an implementation detail relevant to
the CPU loop based delay routine only and more confined to it. In the
mean time this is the minimal fix needed to have expected delays with
the timer based implementation when cpufreq is also in use.

Change-Id: I75f66afe0cd4851031c71c1ebd522b402bb0a788
Reported-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Nicolas Pitre <nico@linaro.org>
Tested-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Liviu Dudau <Liviu.Dudau@arm.com>
Cc: stable@vger.kernel.org
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: MassStash <MassStash@gmail.com>
ARM: 7685/1: delay: use private ticks_per_jiffy field for timer-based delay ops

Commit 70264367a243 ("ARM: 7653/2: do not scale loops_per_jiffy when
using a constant delay clock") fixed a problem with our timer-based
delay loop, where loops_per_jiffy is scaled by cpufreq yet used directly
by the timer delay ops.

This patch fixes the problem in a more elegant way by keeping a private
ticks_per_jiffy field in the delay ops, independent of loops_per_jiffy
and therefore not subject to scaling. The loop-based delay continues to
use loops_per_jiffy directly, as it should.

Change-Id: I675a5089c2156c01e7c2e151c7be2795cf965091
Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: MassStash <MassStash@gmail.com>