Input: Send events one packet at a time

On heavy event loads, such as a multitouch driver, the irqsoff latency
can be as high as 250 us.  By accumulating a frame worth of data
before passing it on, the latency can be dramatically reduced.  As a
side effect, the special EV_SYN handling can be removed, since the
frame is now atomic.

This patch adds the events() handler callback and uses it if it
exists. The latency is improved by 50 us even without the callback.

Change-Id: Iebd9b1868ae6300a922a45b6d104e7c2b38e4cf5
Cc: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Benjamin Tissoires <benjamin.tissoires@enac.fr>
Tested-by: Ping Cheng <pingc@wacom.com>
Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Henrik Rydberg <rydberg@euromail.se>

Input: Improve the events-per-packet estimate

The events-per-packet estimate has so far been used by MT devices
only. This patch adjusts the packet buffer size to also accomodate the
KEY and MSC events.  Keyboards normally send one or two keys at a
time. MT devices normally send a number of button keys along with the
MT information.  The buffer size chosen here covers those cases, and
matches the default buffer size in evdev. Since the input estimate is
now preferred, remove the special input-mt estimate.

Reviewed-and-tested-by: Ping Cheng <pingc@wacom.com>
Tested-by: Benjamin Tissoires <benjamin.tissoires@enac.fr>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
ARM: exynos: manta: increase mem clock in mali dvfs

Lock the memory bus clock at 800 MHz when the GPU is set to 400 MHz or higher.

Signed-off-by: Jamie Gennis <jgennis@google.com>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
mali-t6xx: fix null pointer deref whn dumping MMU page tables

At the moment when if we perform an instrumented dump of the MMU page tables,
the munmap call back will try to free physical pages that are supposed to be
in the memory region allocated for the dump but that are not there,
thus resulting in a NULL pointer exception followed by kernel panic.

In order to solve this, in "kbase_free_phy_pages()" (that is called by the
munmap callback) we need to check the memory region flags to see if
KBASE_REG_IS_MMU_DUMP flag is set.  If it is set then we have to skip the
 call to free the physical pages.

Bug:  7432454
Signed-off-by: Gabriele Paoloni <gabriele.paoloni@arm.com>
Change-Id: I37d5c9f634ae08a1e8340671b15287354c75fd64
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
mali-t6xx: debug patch to trace "dep_item[0]" list abuse

Signed-off-by: Gabriele Paoloni <gabriele.paoloni@arm.com>
Change-Id: I563a4c3c8696fa85505cc97379fb375df034c9bf
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
mali: mark kbase_pm workqueue WQ_MEM_RECLAIM

kbase_cpu_vm_close, which is run in reclaim if the oom killer fires,
waits on the kbase_pm worker.  Mark the kbase_pm worker WQ_MEM_RECLAIM
to make sure it can always run during reclaim, even if there is not
enough memory to spawn new kworkers.

Change-Id: Idf9df2bbf4c70533dc54de31dbe0419ba995eddd
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
gpu: mali: get rid of kbase_page_metadata

Use the lru list_head in the page struct to avoid having to allocate
a struct just to hold the list_head and page pointer.  Also avoids
storing the list_head inside the page for lowmem pages, removing a
cache flush on allocation.

Change-Id: I3400f3109c8839502debb50a754308449bf28f52
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
gpu: mali: add a carveout for gpu memory

Try to allocate gpu memory from a memblock region reserved during
boot to avoid mixing unmovable gpu pages in with all the movable
userspace pages.

All gpu allocations are order 0, so all the free pages are just
stored on a list at boot and allocated off the front of the list.

Change-Id: Idc98981fde85a429046d38ba2ec7c849a50f7713
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
media: exynos: s5p-mfc: prevent suspend while MFC is in use

Change-Id: I6beecbdcb828c20af0f32c1af4d97a163867786a
Signed-off-by: Dima Zavin <dima@android.com>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
media: exynos: mfc: do not release firmware buffer when drm is enabled

The release function already had this check but the error paths in
open did not.

Change-Id: Ida0173787b86ce9df7656dc8e62c07f13916747d
Signed-off-by: Dima Zavin <dima@android.com>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
media: exynos: mfc: get rid of interruptible dev/ctx wait_events

All the current wait_events already have timeouts, so it will never
block forever. The issue is that the current driver does not properly
deal with wait_event returning early when interrupted by system calls.
It ofter ignores the erros and continues, or it will treat it as a
fatal error and tear down contexts while the hardware is still
actively using them. This results in page faults and unexpected
interrupts that crash the system.

So, we turn all the interruptible wait_events into non-interruptible.
This doesn't do anything about the case when the hardware truly times
out, but that problem would have already existed anyway. If the
hardware actually times out, then there's a good chance it is stuck
and will not continue using the state we are about to tear down
(obviously not guaranteed). It will, however, address the most common
case which is getting a signal due to suspend freezing userspace
threads.

Change-Id: If8e5b4335218ec8f8901b4ef7e765a1973bc8d55
Signed-off-by: Dima Zavin <dima@android.com>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
mali: fix section mismatch

Fix a section mismatch between kbase_carveout_mem_reserve and
memblock_alloc_base by adding an __init annotation to
kbase_carveout_mem_reserve.

Change-Id: I348e67530b57325aefd9031574fed5700fee1456
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
usb: gadget: accessory: Fix section mismatch (again)

create_bulk_endpoints should not be __init since it is called when
accessory is enabled.

Change-Id: Iac6e9f29d53c93760e926efd8e7603432632acb4
Signed-off-by: Todd Poynor <toddpoynor@google.com>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
media: exynos: mfc: fix ctx wake up of uninterruptible tasks

Change-Id: I8de46d0619f30799d4fead400ca289358d9aa4e5
Signed-off-by: Dima Zavin <dima@android.com>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
gpu: ion: Fix bug in zeroing pages in system heap

Pages are zeroed for security purposes when returned to the
ion heap.  There was a bug in this code preventing this
from happening.

Bug: 7573871
Change-Id: I79c22ee1da98f306199f3a192eaec4e81d5fd059
Signed-off-by: Rebecca Schultz Zavin <rebecca@android.com>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
media: exynos: mfc: print some debug info in irq on invalid context

Change-Id: I5f857f2aad2c861ad26072555cfcfe217e618090
Signed-off-by: Dima Zavin <dima@android.com>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
gpu: ion: fix carveout ops

when using carveout heap ion_buffer_create function failed because
map_dma and unmap_dma operations aren't set by carveout heap.

Change-Id: I817bfad742abfab10b01d9b3d2e18bdf812a1307
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
gpu: ion: fix compilation warning

use atomic_read to get the refcount value to avoid compilation warning

Change-Id: I9bf0a07c787af8f87ac19314f996a78142f72f6b
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
media: exynos: mfc: reject suspend if the MFC is busy

This lifts the burden of trying to suspend/resume MFC and makes
the behavior a lot more deterministic.

Bug: 7261738
Change-Id: I7c09661d5001f9a8985bcc6ca52ec7ea38a66186
Signed-off-by: Dima Zavin <dima@android.com>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
media: exynos: mfc: don't drop wakeup source in multiple context case

Wakeup sources aren't ref counted, but we we always dropping ours in
release. If there were multiple contexts open, it would allow suspend
even though the MFC was still in use. Although, by itself, it's not a
problem, it did not have the intended effect.

Bug: 7261738
Change-Id: Id42006b2cff0e84711047a149a8654ed950f012a
Signed-off-by: Dima Zavin <dima@android.com>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
media: exynos: mfc: don't deref curr_ctx for dev-global irq reasons

Device-global interrupts (sleep/wake/status/init) can happen without
curr_ctx being valid. Specifically, this has happened when a sleep
request (called from s5p_mfc_suspsend()) immediately
follows a context being released. The driver doesn't reset curr_ctx
to an invalid value, so it is possible to have curr_ctx contain a
stale value when the device irqs are processed.

Ideally, the driver should be fixed to understand that curr_ctx
can have an invalid value, but there are a lot of references and
it would take a lot of time to audit them all and figure out which
situations warrant a check and which do not. It would also not be
a trivial and easily testable change.

So, instead, we isolate the irq reasons that do not rely on
current context being valid, and check them separately before
continuing to context-specific irq processing.

Bug: 7261738
Change-Id: I4eb557ae587b6287429776c98931e8fd096502ce
Signed-off-by: Dima Zavin <dima@android.com>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>