Revert "msm: kgsl: Protect the mem_entry list during deletion"

This reverts commit dacf91dff781e9d416a0e812d80c62681ea8894a.
msm: kgsl: add IOCTL_KGSL_GPUMEM_ALLOC_ID

Previously, the gpu address has been used to uniquely
identify each memory allocation. Upcoming patches will
introduce cases where an allocation does not always
have a gpu address, so an additional id is needed.

IOCTL_KGSL_GPUMEM_ALLOC_ID allocates pages and returns
an id.

IOCTL_KGSL_GPUMEM_FREE_ID frees an id. KGSL_SHAREDMEM_FREE
can still be used to free by GPU address, if it exists.

The id can also be passed to mmap(), shifted left by
PAGE_SIZE to get a CPU mapping for the buffer.

IOCTL_KGSL_GPUMEM_ALLOC_GET_INFO can be called to retrieve
the id and other information about the buffer.

Change-Id: I4b45f0660cb9d4a5fb1323ccc6c4aa360791c1ec
Signed-off-by: Jeremy Gebben <jgebben@codeaurora.org>
msm: kgsl: Support user-specified caching hints

The user allocating memory can provide hints for the caching
settings when said buffer is mapped on the user side. Try
to obey the cache settings when applicable.  The user will
be responsible for handling cache management both to and
from the GPU so add a new ioctl IOCTL_KGSL_GPUMEM_CACHE_SYNC to
support both directions (the old IOCTL_KGSL_SHAREDMEM_FLUSH_CACHE)
only handled flushing, not invalidating. The legacy ioctl still
works it just does what it says it does - a cache flush.

Change-Id: Ic0dedbad55ce82f2b01ebc56de30d4649e2e7311
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
msm: kgsl: allow consistent CPU and GPU mappings

KGSL_GPUMEM_ALLOC_ID now takes a flag,
KGSL_MEMFLAGS_USE_CPU_MAP. When set, the GPU
mapping will be set up to match the CPU mapping
during mmap().  This feature is only supported when
using per process pagetables with the IOMMU. The
flags field of KGSL_GPUMEM_ALLOC_ID is copied back
to userspace and KGSL_MEMFLAGS_USE_CPU_MAP will
be cleared when this feature is not supported.

The IOMMU virtual address space has been adjusted
when perprocess pagetables is enabled so that the
entire userpace address range (0 to TASK_SIZE) can
have equivalent mappings on the IOMMU. For buffers
that do not have equivalent mappings, the address
range from PAGE_OFFSET to KGSL_IOMMU_GLOBAL_MEM_BASE
is used.

Change-Id: Ib61c03aa7453c3dd901c41e8fd297f66d402ae1a
Signed-off-by: Jeremy Gebben <jgebben@codeaurora.org>
msm: kgsl: don't fault in cached allocations

Make sure cache operations don't hit pagefaults by
backing the entire vma in mmap() instead of faulting
in pages as they're touched. Otherwise, there's a
chance that a later cache operation on the mapping
could trigger an unhandled page fault leading to
a kernel panic.

Change-Id: Ia73c8aaed2708c5b9ef46ed50fb0f5cf1ad2450c
Signed-off-by: Jeremy Gebben <jgebben@codeaurora.org>
msm: kgsl: Do not dump the istore on A3XX cores

The instruction store on A3XX GPU cores isn't really an instruction store
as on A2XX and it doesn't give us any debugging value. On top of all
that it can be unstable to read in some situations. Since it is of
questionable value and questionable stability pull it from the snapshot
for all A3XX cores and move the functionality to the A2XX specific code.

Change-Id: Ic0dedbada32d8b6b9b93768d148c2624faf3ef30
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
msm: kgsl: Log retired timestamps on device wake

Knowing the retired timestamp on wake-up is useful to debug hangs that
are caused due to clock instability. When we request for clock ON, the
clock may/may-not be turned ON, but we go ahead assuming it is ON. This
can be caught by printing the timestamp on wake. The timestamp we print,
can be compared against the timestamp in postmortem dump (assuming a
hang happens).

If there is a difference, we can say that GPU has run for sometime after
wake. So, we needn't suspect clocks.

If there is no difference, we can say that GPU has hung immediately after
wake. So, we can positively suspect the clocks.

Change-Id: Iedf49977adbb0e61a9b71bbe23acc81f2a75162d
Signed-off-by: Ranjhith Kalisamy <ranjhith@codeaurora.org>
msm: kgsl: Add identifier for internal command submissions

Add an identifier to label internal commands being sent to the
ringbuffer.  This will be used to further enable debugging
and hang recovery.

Change-Id: I4b3c10f0c3d290ae092182cbb450abe65e9dda80
Signed-off-by: Carter Cooper <ccooper@codeaurora.org>
msm: kgsl: Add CP_WAIT_FOR_IDLE packet before updating timestamp

HW workaround to resolve MMU pagefault caused by memory
freeing early before GPU completes it.

This is race condition where timestamp is getting updated
and the event handler runs before the GPU actually got done
with the timestamp, hence freeing the buffer early while GPU
still not completed with it.

Change-Id: I6d338d7dca680f57f2c39ed5a14381b261bf8bce
Signed-off-by: Anshuman Dani <adani@codeaurora.org>
msm: kgsl: Return correct timestamp for consumed timestamp reads

adreno_readtimestamp() would return a register value when asked to
get the KGSL_TIMESTAMP_CONSUMED value.  With per-context timestamps
this no longer holds valid since the value in the register could
correspond to a different contexts timestamp.  Return the start of
packet timestamp for the specified context now that the start of
timestamp values are correctly submitted.

CRs-fixed: 382888
Change-Id: Iad56d07eb4a2973a5906d989c96dd117ff902cea
Signed-off-by: Carter Cooper <ccooper@codeaurora.org>
msm: kgsl: Verify the user doesn't accidentally submit a zero length IB

Indirect buffers to be executed will not be (and cannot be) zero length.
Check and reject.

Change-Id: Ic0dedbadea429c4f7bd386c5e64603b51ea8af61
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
msm: kgsl: Add a ftrace event for register writes

It is interesting to know when and how we program the hardware so
add a tracepoint to monitor register writes.  Register reads are
not traced since they are done much more frequently and are somewhat
less interesting from a debug perspective.

Change-Id: Ic0dedbad8ee85f154b9ba8731fe2c14603351243
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>