gpu: ion: use a list instead of a tree for heap debug memory map

Currently we use an rb tree to store information about the memory map
which gets passed to the heap print_debug functions. The reason for
using a tree instead of a simple list is to maintain sortedness as we
build the memory map. However, it can be necessary to store multiple
entries for the same address in the memory map since there can be
multiple clients with handles to the same buffer. This information is
interesting and useful but we currently can't store and display it since
the rb tree requires that the key used for sorting (the physical address
in this case) be unique. Fix this by replacing the rb tree with a linked
list. In order to maintain sorted output of the print_debug functions,
sort the list by physical address after fully building the list.

This also has the positive side-effect of simplifying the code and
making future print_debug methods less error-prone.

CRs-Fixed: 571918
Change-Id: I5b129fd809fb53c66042eab10d096238a34c2b20
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
gpu: ion: fix locking issues in debug code

There are a few places in Ion where we are iterating over volatile rb
trees without proper locking. In some places the proper locking cannot
be added since it would require us to take locks in a different order
than they are taken in other places in Ion. Fix this by re-working some
of the debug code so that we can take locks in an allowed order.

One side-effect of the re-work is that the memory maps will now show
every client that has a handle to a particular region of memory, rather
than just showing the first one that we encounter. This will allow for
more accurate accounting and will give better insight as to who is
actually using the memory.

CRs-Fixed: 571918
Change-Id: Ia43e4dbc412cd480c828173f8c20b5095d87d858
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
gpu: ion: add locking to traversal of volatile rb tree

In ion_debug_heap_show we're iterating over an rb tree (dev->clients)
that could change while we're iterating. Fix this by taking the lock
that is used to control access to this tree.

CRs-Fixed: 571918
Change-Id: I6832e1e98e2d2a69fc653451d3752d43ec3ef269
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
gpu: ion: Explictly mark DMA allocations as GFP_KERNEL

For legacy reasons, the GFP allocation for dma allocations is currently
marked as 0, which corresponds to atomic allocations. These allocations
should not be marked as atomic since the atomic pool is very small.
Switch to properly using GFP_KERNEL to always allocate from the
correct pool.

Change-Id: Id3ce68b538a3d6dbdc8857109cca9ec8706ca4ef
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
gpu: ion: Flush the chunk list before passing it to trustzone

Previously, the function scm_call used to take care of flushing
the caches to ensure all data was written back to memory before
going into the secure world. The behavior of scm_call is changing
such that clients are expected to flush caches themselves. Since
the address that the chunk list is written to is cached, we need
to ensure that the data is actually written back. Add the appropriate
cache operations on the chunk list.

Change-Id: I05e6fa868409255e66f1f37f98199c5a7e81882c
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
msm: kgsl: Print a message when tz_init fails

When the tz_init fails to initialize the GPU busy percentage
based algorithm, print an error message and revert to the old
algorithm.

Change-Id: I55a09db7d6f33f6496584fd24c9cfc8a70d13e3d
Signed-off-by: Suman Tatiraju <sumant@codeaurora.org>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
msm: kgsl: convert pwrscale framework to use devfreq

Convert the clock frequency scaling infrastructure to
be based on devfreq.

Change-Id: I1a60ba339db5715a8836b835bd1b29b46e151af6
Signed-off-by: Jeremy Gebben <jgebben@codeaurora.org>
Signed-off-by: Vladimir Razgulin <vrazguli@codeaurora.org>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
msm: kgsl: make msm-adreno-tz the default governor for adreno

On targets where trustzone is available, use the trustzone
based governor instead of simple_ondemand.

Change-Id: Ie11c57684fc63a26e82a5c4816a35a327a1bf945
Signed-off-by: Jeremy Gebben <jgebben@codeaurora.org>
Signed-off-by: Vladimir Razgulin <vrazguli@codeaurora.org>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
PM / devfreq: improve devfreq->data support

This field is treated as governer specific data for
a devfreq instance. But there's currently no way to
set the correct data when switching governors through
sysfs. Add support for optionally passing a set of
name / data pairs in struct devfreq_dev_profile,
representing the data for each governor.

Change-Id: I5523ce94f8b0045974f0635fb734cb1282512f91
Signed-off-by: Jeremy Gebben <jgebben@codeaurora.org>
Signed-off-by: Vladimir Razgulin <vrazguli@codeaurora.org>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
PM / devfreq: allow governors to use devfreq_get_freq_level

Level based governors may need to perform this lookup to
interpret the current frequency of the device.

Change-Id: Idf7246b05775a52f088c52b898d98fbab4fd942c
Signed-off-by: Jeremy Gebben <jgebben@codeaurora.org>
Signed-off-by: Vladimir Razgulin <vrazguli@codeaurora.org>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
PM / devfreq: fix find_governor_data() function

find_governor_data() was added to the devfreq infrastructure earlier.
It uses an incorrect condition in an if-statement when it searches
a governor by its name. Fixing the condition.

Change-Id: Ib297caad3e23984651217a43d2fdde1f6fcbdf7a
Signed-off-by: Vladimir Razgulin <vrazguli@codeaurora.org>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
PM / devfreq: add msm-adreno-tz governor

This governor can be used to control adreno GPUs.
It is unlikely to be useful for other devices.

Change-Id: Icf481322454b814d2f41019f2f01286062409952
Signed-off-by: Jeremy Gebben <jgebben@codeaurora.org>
Signed-off-by: Vladimir Razgulin <vrazguli@codeaurora.org>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
PM / devfreq: Allow the governors to set the target flag

The devfreq framework calls a frequency targeting function with
a flag parameter.  Allow the governors to influence that parameter.

Change-Id: I4058bd9dcd027dd246ccdb90d25c68f1dc055901
Signed-off-by: Lucille Sylvester <lsylvest@codeaurora.org>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
msm: kgsl: convert pwrscale to use bus_mod

Use a bus specific speed flag rather than overloading
the least upper bound flag.

Change-Id: I343726e6e0d9885f39c343ed56c1667ab2008aee
Signed-off-by: Lucille Sylvester <lsylvest@codeaurora.org>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
msm: kgsl: Don't spam the kernel log if qcom,step-pwrlevel isn't found

qcom,step-pwrlevel is a specific parameter that only applies to
certain targets.  Don't spam the world if it isn't specified.

CRs-fixed: 556418
Change-Id: Ic0dedbad65dbdcf9bc227fef4a796e22131ba68f
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
msm: kgsl: bus modifier computation

Use the vbif performance counter which counts bus busy cycles
to determine the requested bus bandwidth vote at a given
GPU frequency.

Change-Id: I18915ef8a2be75a7ef5795a6030a1f2ddd09a967
CRs-fixed: 551893
Signed-off-by: Lucille Sylvester <lsylvest@codeaurora.org>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
msm: kgsl: Save/restore performance counters across GPU power collapse

Physical performance counters are reset on GPU power collapse.
Save the values of the performance counters when the GPU goes to
power collapse and restore them on restart.

Change-Id: I63bec7b20e7fe516bbac4901cac0af3a1c1f4959
Signed-off-by: Harshdeep Dhatt <hdhatt@codeaurora.org>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
msm: kgsl: Get CP_RPTR from register instead of shadow memory

Sometimes the RPTR shadow memory is unreliable causing timeouts
in adreno_idle().  Read it directly from the register instead.

Change-Id: Icae7521edd9723610c41f320c6a5c99f57bec7f5
Signed-off-by: Tarun Karra <tkarra@codeaurora.org>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
msm: kgsl: Allow GPU start to run in a high priority queue

The GPU start sequence needs to run with low latency when coming
out of slumber for the first draw command. For those cases allow the
start function to be queued into a high priority workqueue to reduce
the chance of it getting scheduled out.

Change-Id: Ic0dedbada7ef4d63b54e826862fbefdfb71a092a
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
msm: kgsl: Add an input handler to power up the GPU on a touch event

On a device where the primary input is a touchscreen nobody is
surprised that touch events are often the catalyst for drawing
frames. If the GPU is in slumber we can get a jump on the action
by watching for touch events and turning the GPU on in anticipation
of a draw call. Register for events from all input drivers
returning EV_ABS events and queue a work task to power up the GPU
if it is currently in slumber.

Change-Id: Ic0dedbadbdc96ef9ddd78252ea65f8e1cdd00110
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Dan Trifan <jimsth@gmail.com>