sched,cgroup: Fix up task_groups list

With multiple instances of task_groups, for_each_rt_rq() is a noop,
no task groups having been added to the rt.c list instance.  This
renders __enable/disable_runtime() and print_rt_stats() noop, the
user (non) visible effect being that rt task groups are missing in
/proc/sched_debug.

Change-Id: Ib337ebda0e752f838d787c03fe1b0a8f03ea0551
Signed-off-by: Mike Galbraith <efault@gmx.de>
Cc: stable@kernel.org # v3.3+
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1344308413.6846.7.camel@marge.simpson.net
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Git-commit: 35cf4e50b16331def6cfcbee11e49270b6db07f5
Git-repo: git://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git
Signed-off-by: Syed Rameez Mustafa <rameezmustafa@codeaurora.org>
msm: rpm-regulator-smd: fix request suppression policy

The rpm-regulator-smd driver sends requests for a given regulator to
the RPM only if the regulator has been enabled by a Linux consumer.
If the regulator is disabled from Linux's point of view, then voltage
and current requests are buffered until the regulator is enabled again.
This buffering can lead to regulators being left at unnecessarily high
voltages when they are no longer needed.

Modify the request suppression policy so that current and voltage updates
are suppressed only before the first enable/disable request is sent for a
regulator or while the regulator is disabled if it has been marked as
apps-only. The first request sent for a given regulator must provide a
value for the enable/disable parameter otherwise the RPM will treat it as
an implicit disable request. This would break use-cases that require
certain regulators to be left on until sufficient software control is
initialized. Add a new device tree property, qcom,apps-only, which can be
used to specify that a given regulator supplies hardware that is fully
controlled by the applications processor.

CRs-Fixed: 533263
Signed-off-by: Ashay Jaiswal <ashayj@codeaurora.org>
Change-Id: I2a8820662e1471e5ff44f7d681d5d768da74980f
gpiomux-8974: Modify direction of suspended GPIO

changed the direction and strength for some below mentioned GPIOs
as per 8974 suggested GPIO settings in Rockbottom.
With new config 0.400-0.500mA been saved on floor in Audio
use case.
Settings are applicable when there is no user to GPIOs
Following are the changes made:
	GPIO# Changed       What Changed
	24                  IN->OUT 8mA->2mA
	46                  IN->OUT 8mA->2mA
	80                  8mA->2mA
	82                  IN->OUT 8mA->2mA
	104                 IN->OUT 8mA->2mA PD->NO PULL
	105                 IN->OUT 8mA->2mA
	106                 IN->OUT 8mA->2mA

Change-Id: Iaedc91b3d696a588e0723ffb495be179c7e0ae6c
Signed-off-by: Tirtha Kanti Ghosh <tirtha@codeaurora.org>
Merge "msm: rpm-regulator-smd: fix request suppression policy" into LNX.LA.3.5.1.1
Merge "sched,cgroup: Fix up task_groups list" into LNX.LA.3.5.1.1
Merge "gpiomux-8974: Modify direction of suspended GPIO" into LNX.LA.3.5.1.1
msm: kgsl: Force the ME off before reading the microcode

On A3XX reading the microcode while the CP is running is dangerous
beyond words.  By setting the offset address for the read, we are
essentially changing the instruction pointer for the ME while it
is running causing opcode errors, gpu faults and/or system errors.

We do not want to stop the CP at the beginning of the snapshot
process beacuse doing so changes the RBBM status and the state of
the CP registers which may damage the debug effort.  But by the
time we get to the microcode read we no longer care about the state
of the registers so we can freely halt the ME just before starting
the read.

CRs-fixed: 585449
Change-Id: Ic0dedbad85d7ec26915f054dd597e226e8101a29
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
msm: kgsl: Ensure signals do not cause waits to end early

Move to using uninterruptible (which will bail if any signal is received)
when waiting on events.  A signal was causing the wait to finish
prematurely, freeing memory while the GPU was still using it.  This caused
quite a few page faults and the device to become unstable.

Change-Id: Ic0dedbade9143c9377830a209c3ffd252aa9668b
Signed-off-by: Carter Cooper <ccooper@codeaurora.org>
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
msm: kgsl: Panic if global timestamp wait fails in context detach

If we timeout while waiting for the last issued global timestamp for
a detaching context to expire (10 seconds!) then we are on a fast
train to crashville.  BUG_ON() so we can stand a chance of debugging
this very rare issue.

Change-Id: Ic0dedbaddb9cbc5681f9c872785ce26b7cf9b87b
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
msm: kgsl: Don't block on detach if the context is invalid

An invalidated context means that something pretty nasty happened and
likely there was an unrecovered GPU fault along the way. If this is
the case then the GPU is likely not processing commands for the context
anymore. Don't block for the last retired global if the context was
invalidated.

Change-Id: Ic0dedbad22a22b704baf14557d7e18cc4cf1044a
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
msm: kgsl: Change the pagefault policy immediately

When changing the pagefault policy the MMU setting for the pagefault
policy was not changed, add code to do that.

Conflicts:
	drivers/gpu/msm/adreno.c

Change-Id: I3b185a7f6bdda42856c777c60ae82c32b9c52eb9
Signed-off-by: Shubhraprakash Das <sadas@codeaurora.org>
Signed-off-by: Hareesh Gundu <hareeshg@codeaurora.org>
Merge "msm: kgsl: Ensure signals do not cause waits to end early" into LNX.LA.3.5.1.1
Merge "msm: kgsl: Panic if global timestamp wait fails in context detach" into LNX.LA.3.5.1.1
Merge "msm: kgsl: Don't block on detach if the context is invalid" into LNX.LA.3.5.1.1
Merge "msm: kgsl: Change the pagefault policy immediately" into LNX.LA.3.5.1.1
msm: kgsl: Refcount mmu clock calls and allow multiple disable events

Allow each mmu clock enable call to enable the clock and let the
clock driver refcounting mechanism deal with switching the clock
off at the right time. This also means that each enable call should
have a disable call or a disable event registered, so allow for
multiple disable events to be registered. This simplifies the mmu
clock handling mechanism which is better for multiple ringbuffer
implementation. With multiple ringbuffers each global timestamp is
tied to a specific ringbuffer and with a single clock disable event
it is hard to figure out when the clock should be turned off.

CRs-fixed: 597193 592485
Change-Id: I924c545140bd19d95890a5fdfd0382c511abe973
Signed-off-by: Shubhraprakash Das <sadas@codeaurora.org>
Signed-off-by: Tarun Karra <tkarra@codeaurora.org>