msm: mdss: Use interruptible threads

Based on @cyanogen's findings, use interruptible threads to reduce
cpu load.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
msm: mdss: call suspend and resume panel events during runtime triggers

Send a panel suspend/resume event to all the MDSS devices to ensure
proper handling of regulators and clocks during the suspend/resume
sequence.

Change-Id: I820f5e4113f599ba53d4fa4726e406f74872f95f
Signed-off-by: Sree Sesha Aravind Vadrevu <svadrevu@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
ARM: dts: Disable RPM notifications for L2 GDHS collapse on Krait targets

Entering vdd minimization is unsupported during L2 GDHS collapse.
Prevent this from happening by not notifying the RPM during the L2
GDHS SPM sequence.

CRs-Fixed: 609356
Change-Id: Iefcb3597df5af104f823fdfb1ad1879f5d1d057e
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
softirq: Use hotplug thread infrastructure

[ paulmck: Call rcu_note_context_switch() with interrupts enabled. ]

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Reviewed-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Link: http://lkml.kernel.org/r/20120716103948.456416747@linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
rcu: Yield simpler

The rcu_yield() code is amazing. It's there to avoid starvation of the
system when lots of (boosting) work is to be done.

Now looking at the code it's functionality is:

 Make the thread SCHED_OTHER and very nice, i.e. get it out of the way
 Arm a timer with 2 ticks
 schedule()

Now if the system goes idle the rcu task returns, regains SCHED_FIFO
and plugs on. If the systems stays busy the timer fires and wakes a
per node kthread which in turn makes the per cpu thread SCHED_FIFO and
brings it back on the cpu. For the boosting thread the "make it FIFO"
bit is missing and it just runs some magic boost checks. Now this is a
lot of code with extra threads and complexity.

It's way simpler to let the tasks when they detect overload schedule
away for 2 ticks and defer the normal wakeup as long as they are in
yielded state and the cpu is not idle.

That solves the same problem and the only difference is that when the
cpu goes idle it's not guaranteed that the thread returns right away,
but it won't be longer out than two ticks, so no harm is done. If
that's an issue than it is way simpler just to wake the task from
idle as RCU has callbacks there anyway.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Namhyung Kim <namhyung@kernel.org>
Reviewed-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Link: http://lkml.kernel.org/r/20120716103948.131256723@linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
rcu: Use smp_hotplug_thread facility for RCUs per-CPU kthread

Bring RCU into the new-age CPU-hotplug fold by modifying RCU's per-CPU
kthread code to use the new smp_hotplug_thread facility.

[ tglx: Adapted it to use callbacks and to the simplified rcu yield ]

Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Namhyung Kim <namhyung@kernel.org>
Link: http://lkml.kernel.org/r/20120716103948.673354828@linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Revert "msm: krait-regulator-pmic: Add krait-regulator-pmic driver"

This reverts commit 174cc68f65f70a024891b00ea83aaea7e49448ba.
Revert "msm: krait-regulator: enable support for KPSS v2 hardware"

This reverts commit cc10c72395f663c390f333df3d17c57352ea7618.
Revert "msm: krait-regulator: fix the cold boot sequence"

This reverts commit 66a073f2329b5ef48baec4c2ee3f912cfac63c9a.
Revert "msm: krait-regulator: Add flag to disable LDO mode usage"

This reverts commit 1b0be3b39c953b95c262b5099ef37d6d4e3eb760.
3.4.78

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
3.4.79

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
qseecom: Fix issues with failure to release client handle

There exists scenarios when qseecom_release is called,
the client handle type is incorrect; hence proper cleanup
is not done with regards to unloading app or cleaning up
memory allocated for the device handle.
This change addresses all cleanup issues related to qseecom
client in qseecom_release call by ensuring the handle type is
set correctly and cleanup is done properly based on client type.

Change-Id: I126aa431ce635ae98100b774e3d92b704635d199
Signed-off-by: Hariprasad Dhalinarasimha <hnamgund@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
msm: msm_bus: Don't divide RPM BW requests

When sending bandwidth requests to slave don't divide the request by
the number of ports as this is done at the RPM driver.

CRs-Fixed: 611965
Change-Id: Ie6870b66d1621677d94e4441136aed89bbdb6595
Signed-off-by: Girish Mahadevan <girishm@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
msm: kgsl: Pass the right timeout to adreno_drawctxt_wait()

adreno_drawctxt_wait() expects the passed in timeout to be in
milliseconds and converts it to jiffies.  Unfortunately, so does
the caller so the timeout is shorter than it should be.

Change-Id: Ic0dedbad85d50b32dba0fbf3ebb914335bf55166
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
msm: kgsl: Fix the api type in adreno drawctxt flags

Adding the missed type field in adreno draw ctxt create
which was giving incorrect data type.

CRs-Fixed: 590103

Signed-off-by: Anoop Kumar Yerukala <ayeruk@codeaurora.org>
Signed-off-by: Prabhat Awasthi <pawasthi@codeaurora.org>
Change-Id: I6f464a3b6cc1fec3891d1189f85c7fe9ac65764e
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
mm/page-writeback.c: fix dirty_balance_reserve subtraction from dirtyable memory

Tejun reported stuttering and latency spikes on a system where random
tasks would enter direct reclaim and get stuck on dirty pages.  Around
50% of memory was occupied by tmpfs backed by an SSD, and another disk
(rotating) was reading and writing at max speed to shrink a partition.

: The problem was pretty ridiculous.  It's a 8gig machine w/ one ssd and 10k
: rpm harddrive and I could reliably reproduce constant stuttering every
: several seconds for as long as buffered IO was going on on the hard drive
: either with tmpfs occupying somewhere above 4gig or a test program which
: allocates about the same amount of anon memory.  Although swap usage was
: zero, turning off swap also made the problem go away too.
:
: The trigger conditions seem quite plausible - high anon memory usage w/
: heavy buffered IO and swap configured - and it's highly likely that this
: is happening in the wild too.  (this can happen with copying large files
: to usb sticks too, right?)

This patch (of 2):

The dirty_balance_reserve is an approximation of the fraction of free
pages that the page allocator does not make available for page cache
allocations.  As a result, it has to be taken into account when
calculating the amount of "dirtyable memory", the baseline to which
dirty_background_ratio and dirty_ratio are applied.

However, currently the reserve is subtracted from the sum of free and
reclaimable pages, which is non-sensical and leads to erroneous results
when the system is dominated by unreclaimable pages and the
dirty_balance_reserve is bigger than free+reclaimable.  In that case, at
least the already allocated cache should be considered dirtyable.

Fix the calculation by subtracting the reserve from the amount of free
pages, then adding the reclaimable pages on top.

[akpm@linux-foundation.org: fix CONFIG_HIGHMEM build]
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Reported-by: Tejun Heo <tj@kernel.org>
Tested-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Rik van Riel <riel@redhat.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Wu Fengguang <fengguang.wu@intel.com>
Reviewed-by: Michal Hocko <mhocko@suse.cz>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
mm/page-writeback.c: do not count anon pages as dirtyable memory

The VM is currently heavily tuned to avoid swapping.  Whether that is
good or bad is a separate discussion, but as long as the VM won't swap
to make room for dirty cache, we can not consider anonymous pages when
calculating the amount of dirtyable memory, the baseline to which
dirty_background_ratio and dirty_ratio are applied.

A simple workload that occupies a significant size (40+%, depending on
memory layout, storage speeds etc.) of memory with anon/tmpfs pages and
uses the remainder for a streaming writer demonstrates this problem.  In
that case, the actual cache pages are a small fraction of what is
considered dirtyable overall, which results in an relatively large
portion of the cache pages to be dirtied.  As kswapd starts rotating
these, random tasks enter direct reclaim and stall on IO.

Only consider free pages and file pages dirtyable.

Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Reported-by: Tejun Heo <tj@kernel.org>
Tested-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Rik van Riel <riel@redhat.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Wu Fengguang <fengguang.wu@intel.com>
Reviewed-by: Michal Hocko <mhocko@suse.cz>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>