Revert "board-pico.h: allow to rework memory a *little* (experimental)"

This reverts commit 268c1ea54e00670d8e71625e636d66b0dc652417.

*experimental*
*not* something we want right away.
Revert "aw3som3: rearrange and relay the partition table"

This reverts commit 21b5345da4ea34fddfaa3267ca0170142efb9ed1.
Revert "aw3som3: set msm_nand_data.parts later"

This reverts commit dd7001e0aafde41d74f45f4a9b8b7791ac39c25a.
Revert "pico_defconfig: enable aw3som3"

This reverts commit c7cd955f78f4ef3740066dedd0d3823850b30b0b.
Revert "aw3som3: hax the partition table!"

This reverts commit 081a58bbc62813f29caef801ab6081b20676a309.
awesom3: hax the partition table!

dynamically resize the partition table for the
device HTC Explorer (codename 'pico')
pico_defconfig: enable awesom3
kgsl: fix genalloc BUG when detroying pagetable.

kgsl allocs some memory (in map_global), but never free it.
Fixes that.
Only happens when on GPUMMU ..
Update genlock from kk_2.7_rb1.6
Update framebuffer from CAF msm-3.4
mipi_samsung: Use mipi_dsi_cmds_tx2

make sure mdp dma is not txing pixel data
mipi_samsung: Call bkl_ctrl from lcd_on
mipi_samsung: Enable bkl from display on cmds
mipi_samsung: Use mipi_dsi_cmds_tx

Use DTYPE_DCS_LWRITE in backlight_cmds to fix black screen on brightness change
writeback: fix writeback cache thrashing

Consider Process A: huge I/O on sda
        doing heavy write operation - dirty memory becomes more
        than dirty_background_ratio
        on HDD - flusher thread flush-8:0

Consider Process B: small I/O on sdb
        doing while [1]; read 1024K + rewrite 1024K + sleep 2sec
        on Flash device - flusher thread flush-8:16

As Process A is a heavy dirtier, dirty memory becomes more
than dirty_background_thresh. Due to this, below check becomes
true(checking global_page_state in over_bground_thresh)
for all bdi devices(even for very small dirtied bdi - sdb):

In this case, even small cached data on 'sdb' is forced to flush
and writeback cache thrashing happens.

When we added debug prints inside above 'if' condition and ran
above Process A(heavy dirtier on bdi with flush-8:0) and
Process B(1024K frequent read/rewrite on bdi with flush-8:16)
we got below prints:

[Test setup: ARM dual core CPU, 512 MB RAM]

[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  56064 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  56704 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 84720 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 94720 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   384 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   960 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =    64 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 92160 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   256 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   768 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =    64 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   256 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   320 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =     0 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 92032 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 91968 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   192 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =  1024 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =    64 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   192 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   576 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =     0 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 84352 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   192 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   512 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =     0 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 92608 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 92544 KB

As mentioned in above log, when global dirty memory > global background_thresh
small cached data is also forced to flush by flush-8:16.
If removing global background_thresh checking code, we can reduce cache
thrashing of frequently used small data.
And It will be great if we can reserve a portion of writeback cache using
min_ratio.

After applying patch:
$ echo 5 > /sys/block/sdb/bdi/min_ratio
$ cat /sys/block/sdb/bdi/min_ratio
5
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  56064 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  56704 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  84160 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  96960 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  94080 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  93120 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  93120 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  91520 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  89600 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  93696 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  93696 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  72960 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  90624 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  90624 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  90688 KB

As mentioned in the above logs, once cache is reserved for Process B,
and patch is applied there is less writeback cache thrashing on sdb
by frequent forced writeback by flush-8:16 in over_bground_thresh.

After all, small cached data will be flushed by periodic writeback
once every dirty_writeback_interval.

Suggested-by: Wanpeng Li <liwanp@linux.vnet.ibm.com>
Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com>
Signed-off-by: Vivek Trivedi <t.vivek@samsung.com>

The original code has been modified to compile on this Kernel version.

Change-Id: Ib14b6f04efbfd61e9375c2c05082f123c604bec0
mm: pass readahead info down to the i/o scheduler

Some i/o schedulers (i.e. row-iosched, cfq-iosched) deploy an idling
algorithm in order to be better synced with the readahead algorithm.
Idling is a prediction algorithm for incoming read requests.

In this patch we mark pages which are part of a readahead window, by
setting a newly introduced flag. With this flag, the i/o scheduler can
identify a request which is associated with a readahead page. This
enables the i/o scheduler's idling mechanism to be en-sync with the
readahead mechanism and, in turn, can increase read throughput.

Change-Id: I0654f23315b6d19d71bcc9cc029c6b281a44b196
Signed-off-by: Lee Susman <lsusman@codeaurora.org>
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.

Conflicts:
	drivers/gpu/msm/adreno_a3xx_snapshot.c

Change-Id: Ic0dedbad85d7ec26915f054dd597e226e8101a29
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Sunil Khatri <sunilkh@codeaurora.org>
Staging: android: binder: More offset validation.

Make sure offsets don't point to overlapping flat_binder_object
structs.

Conflicts:
	drivers/staging/android/binder.c

Change-Id: I425ab0c46fbe2b00ed679c5becf9e8140395eb40
Signed-off-by: Arve Hjønnevåg <arve@android.com>
Git-commit: 457c3cd05958b8397211ae1f6dd3c3d325f4c0ea
Git-repo: https://android.googlesource.com/kernel/common/
Signed-off-by: Neeti Desai <neetid@codeaurora.org>
Signed-off-by: Ajay Dudani <adudani@codeaurora.org>
Signed-off-by: Nirmal Abraham <nabrah@codeaurora.org>
Signed-off-by: Prados Das <prados@codeaurora.org>
msm: kgsl: Increase the timeout value for fault detection

Increment the timeout value for detecting faults from 50ms to
200ms. The fault detection mechanism is a backup to hardware
fault detection. 50ms is small since it has been observed that
this mechanism triggers false positives with 50ms.

CRs-Fixed: 672164
Change-Id: I8f382051e06bdc47f152309a2868092e1980604e
Signed-off-by: Shubhraprakash Das <sadas@codeaurora.org>
Signed-off-by: Tarun Karra <tkarra@codeaurora.org>
Signed-off-by: Sunil Khatri <sunilkh@codeaurora.org>
msm: kgsl: Don't hold the refernce to the process private in kgsl create context

There is a possible race condition for dev_priv where the kgsl_release
is called, while adreno_ft_detect has reference for the same context.
This change will avoid to use dev_priv in context destroy, which is
already freed in kgsl_release.

CRs-Fixed: 688521
Change-Id: I0411873b605c4e264057eaa3f79c6439004c427c
Signed-off-by: Gaurav Gagrani <ggagrani@codeaurora.org>