Missing updat for ion from caf jb_mr1_chocolate

Change-Id: Ide99d7f5f5465716ee250e1f08696f8b175a9a38
Saga : Update for pmem+ion

Change-Id: I6bf648aee48b2a40177e9270a23df2018c1ff0e2
Saga : update defconfig
Revert "msm: ion: Only return Ion flags in ion_handle_get_flags"

This reverts commit 92e841512949ec7f5f9d6079082ec818649c9864.
Revert "gpu: ion: move msm-specific ioctls to custom_ioctl"

This reverts commit 719aa810d7d3d9dcf36d879103ada5a3aa9ff8f8.
Revert "gpu: ion: repurpose flags field for heap_mask and caching"

This reverts commit 4334740161b19e5d736796f839c4aaa5964b74c7.
msm: rotator: sync point support

Add MSM_ROTATOR_IOCTL_BUFFER_SYNC ioctl interface.
Rotator will create a timeline for each session at START, wait for
input fence and create released fence in this ioctl call,
signal the timeline after rotation is done.

Change-Id: I3738f8287d804ccd94e0a16ac0afb8b41b299c75
Signed-off-by: Ken Zhang <kenz@codeaurora.org>

Conflicts:
	drivers/char/msm_rotator.c
msm: rotator: use fd_info instead of rot_session
msm: rotator: use first_free_index instead of first_free_idx
msm: rotator: Add pseudo-planar 422 H1V2 dst format for MDP4

For interleaved 422 inputs, rotator outputs MDP_Y_CRCB_H1V2
format on 90 degree rotation. Add support as destination format
for MDP4.

CRs-Fixed: 371303
Change-Id: Ie0f98d40f58bf2cb9bc3298a94cae9c4e89b2f7a
Signed-off-by: Mayank Chopra <makchopra@codeaurora.org>
msm: rotator: add YUV444 interleave format support

Add support for H1V1 interleave (YUV444) to rotator
in msm_rotator_get_plane_sizes().

Change-Id: I57ff5236b7e9329b72f9983da9874de938a821a2
Signed-off-by: Kyong Hwa Bae <kbae@codeaurora.org>
msm: rotator: add YUV444 interleave format support

Add support for H1V1 interleave (YUV444) to rotator

Change-Id: I772ff1823e3c9acf046d339c3a1eeb1ab324b279
Signed-off-by: Kyong Hwa Bae <kbae@codeaurora.org>
Signed-off-by: Adrian Salido-Moreno <adrianm@codeaurora.org>
drivers/gpu: update to CAF jb_vanilla adreno drivers

Last commit is: msm: Add support for ION Flushing without virtual addresses
drivers/video: rollback some vidc changes to fix camcorder
video/msm: copy the CAF jb_vanilla msm_fb driver

Last commit is Merge "msm: display: msm_fb: Fix hang when framework
is rebooted in suspend mode"
https://www.codeaurora.org/cgit/quic/la/kernel/msm/commit/drivers/video/msm?h=jb_vanilla&id=2340c90a75a2a72316b6e70835bcb2b21a69a113

Conflicts:
	drivers/video/msm/mdp4_overlay_dsi_video.c
	drivers/video/msm/mdp4_overlay_lcdc.c
	include/linux/msm_mdp.h
dma-buf: mmap support

Compared to Rob Clark's RFC I've ditched the prepare/finish hooks
and corresponding ioctls on the dma_buf file. The major reason for
that is that many people seem to be under the impression that this is
also for synchronization with outstanding asynchronous processsing.
I'm pretty massively opposed to this because:

- It boils down reinventing a new rather general-purpose userspace
  synchronization interface. If we look at things like futexes, this
  is hard to get right.
- Furthermore a lot of kernel code has to interact with this
  synchronization primitive. This smells a look like the dri1 hw_lock,
  a horror show I prefer not to reinvent.
- Even more fun is that multiple different subsystems would interact
  here, so we have plenty of opportunities to create funny deadlock
  scenarios.

I think synchronization is a wholesale different problem from data
sharing and should be tackled as an orthogonal problem.

Now we could demand that prepare/finish may only ensure cache
coherency (as Rob intended), but that runs up into the next problem:
We not only need mmap support to facilitate sw-only processing nodes
in a pipeline (without jumping through hoops by importing the dma_buf
into some sw-access only importer), which allows for a nicer
ION->dma-buf upgrade path for existing Android userspace. We also need
mmap support for existing importing subsystems to support existing
userspace libraries. And a loot of these subsystems are expected to
export coherent userspace mappings.

So prepare/finish can only ever be optional and the exporter /needs/
to support coherent mappings. Given that mmap access is always
somewhat fallback-y in nature I've decided to drop this optimization,
instead of just making it optional. If we demonstrate a clear need for
this, supported by benchmark results, we can always add it in again
later as an optional extension.

Other differences compared to Rob's RFC is the above mentioned support
for mapping a dma-buf through facilities provided by the importer.
Which results in mmap support no longer being optional.

Note that this dma-buf mmap patch does _not_ support every possible
insanity an existing subsystem could pull of with mmap: Because it
does not allow to intercept pagefaults and shoot down ptes importing
subsystems can't add some magic of their own at these points (e.g. to
automatically synchronize with outstanding rendering or set up some
special resources). I've done a cursory read through a few mmap
implementions of various subsytems and I'm hopeful that we can avoid
this (and the complexity it'd bring with it).

Additonally I've extended the documentation a bit to explain the hows
and whys of this mmap extension.

In case we ever want to add support for explicitly cache maneged
userspace mmap with a prepare/finish ioctl pair, we could specify that
userspace needs to mmap a different part of the dma_buf, e.g. the
range starting at dma_buf->size up to dma_buf->size*2. This works
because the size of a dma_buf is invariant over it's lifetime. The
exporter would obviously need to fall back to coherent mappings for
both ranges if a legacy clients maps the coherent range and the
architecture cannot suppor conflicting caching policies. Also, this
would obviously be optional and userspace needs to be able to fall
back to coherent mappings.

v2:
- Spelling fixes from Rob Clark.
- Compile fix for !DMA_BUF from Rob Clark.
- Extend commit message to explain how explicitly cache managed mmap
  support could be added later.
- Extend the documentation with implementations notes for exporters
  that need to manually fake coherency.

Change-Id: Ia8f2ae5d8a1b1c87ed12ca1c89d7bf2067239ee4
Cc: Rob Clark <rob.clark@linaro.org>
Cc: Rebecca Schultz Zavin <rebecca@android.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Conflicts:
	drivers/base/dma-buf.c
	include/linux/dma-buf.h
[PATCH] proofs: add num_to_str() to speed up /proc/stat

== stat_check.py
num = 0
with open("/proc/stat") as f:
        while num < 1000 :
                data = f.read()
                f.seek(0, 0)
                num = num + 1
==

perf shows

    20.39%  stat_check.py  [kernel.kallsyms]    [k] format_decode
    13.41%  stat_check.py  [kernel.kallsyms]    [k] number
    12.61%  stat_check.py  [kernel.kallsyms]    [k] vsnprintf
    10.85%  stat_check.py  [kernel.kallsyms]    [k] memcpy
     4.85%  stat_check.py  [kernel.kallsyms]    [k] radix_tree_lookup
     4.43%  stat_check.py  [kernel.kallsyms]    [k] seq_printf

This patch removes most of calls to vsnprintf() by adding num_to_str()
and seq_print_decimal_ull(), which prints decimal numbers without rich
functions provided by printf().

On my 8cpu box.
== Before patch ==
[root@bluextal test]# time ./stat_check.py

real    0m0.150s
user    0m0.026s
sys     0m0.121s

== After patch ==
[root@bluextal test]# time ./stat_check.py

real    0m0.055s
user    0m0.022s
sys     0m0.030s

[akpm@linux-foundation.org: remove incorrect comment, use less statck
in num_to_str(), move comment from .h to .c, simplify
seq_put_decimal_ull()]
[andrea@betterlinux.com: avoid breaking the ABI in /proc/stat]
Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Signed-off-by: Andrea Righi <andrea@betterlinux.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Glauber Costa <glommer@parallels.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Paul Turner <pjt@google.com>
Cc: Russell King <rmk@arm.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
back ported from Linux 3.4-rc4 to Linux 3.0.x by faux123
fs: seq_file - add event counter to simplify poll() support

Moving the event counter into the dynamically allocated 'struc seq_file'
allows poll() support without the need to allocate its own tracking
structure.

All current users are switched over to use the new counter.

Requested-by: Andrew Morton akpm@linux-foundation.org
Acked-by: NeilBrown <neilb@suse.de>
Tested-by: Lucas De Marchi lucas.demarchi@profusion.mobi
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
genlock: include BIT definition for minimal header includes
fs/sync: Make sync() satisfy many requests with one invocation

Dave Jones reported RCU stalls, overly long hrtimer interrupts, and
amazingly long NMI handlers from a trinity-induced workload involving
lots of concurrent sync() calls (https://lkml.org/lkml/2013/7/23/369).
There are any number of things that one might do to make sync() behave
better under high levels of contention, but it is also the case that
multiple concurrent sync() system calls can be satisfied by a single
sys_sync() invocation.

Given that this situation is reminiscent of rcu_barrier(), this commit
applies the rcu_barrier() approach to sys_sync().  This approach uses
a global mutex and a sequence counter.  The mutex is held across the
sync() operation, which eliminates contention between concurrent sync()
operations.  The counter is incremented at the beginning and end of
each sync() operation, so that it is odd while a sync() operation is in
progress and even otherwise, just like sequence locks.

The code that used to be in sys_sync() is now in do_sync(), and sys_sync()
now handles the concurrency.  The sys_sync() function first takes a
snapshot of the counter, then acquires the mutex, and then takes another
snapshot of the counter.  If the values of the two snapshots indicate that
a full do_sync() executed during the mutex acquisition, the sys_sync()
function releases the mutex and returns ("Our work is done!").  Otherwise,
sys_sync() increments the counter, invokes do_sync(), and increments
the counter again.

This approach allows a single call to do_sync() to satisfy an arbitrarily
large number of sync() system calls, which should eliminate issues due
to large numbers of concurrent invocations of the sync() system call.

Changes since v1 (https://lkml.org/lkml/2013/7/24/683):

o	Add a pair of memory barriers to keep the increments from
	bleeding into the do_sync() code.  (The failure probability
	is insanely low, but when you have several hundred million
	devices running Linux, you can expect several hundred instances
	of one-in-a-million failures.)

o	Actually CC some people who have experience in this area.

Reported-by: Dave Jones <davej@redhat.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Jan Kara <jack@suse.cz>
Cc: Curt Wohlgemuth <curtw@google.com>
Cc: Jens Axboe <jaxboe@fusionio.com>
Cc: linux-fsdevel@vger.kernel.org

Signed-off-by: Paul Reioux <reioux@gmail.com>