msm_fb: display: Add support to YCBYCR MDP format

Add support of MDP_YCBYCR_H2V1 interleaved YUV format to MDP
for a-family targets.

Change-Id: I5afb84a95693d1ced114152364782a10c4d56bc2
Signed-off-by: Mayank Chopra <makchopra@codeaurora.org>
msm: rotator: Add support to YCBYCR rotator format

Add support for MDP_YCBYCR_H2V1 interleaved YUV format in rotator
block.

Change-Id: I4bb192aaab1e72f6e5687ae222a5f9ea2c254bd4
Signed-off-by: Mayank Chopra <makchopra@codeaurora.org>
Use 4.7 toolchain

Change-Id: I44cbe0cd9aa7de92bdf97d263584f6e73175bb65
fs/dyn_sync_cntrl: dynamic sync control

The dynamic sync control interface uses Android kernel's unique early
suspend / lat resume interface.

While screen is on, file sync is disabled
when screen is off, a file sync is called to flush all outstanding writes
and restore file sync operation as normal.

Change-Id: Ia70cf7bbd3c3b5ef597341715d2f01f577d8bd55
Add and enable FRandom

Change-Id: I0761b2ce746e4c1aa4ed8d292b2b1c324af39640
mm: Dynamic management of dirty page writebacks

Change-Id: Ia3c879928cb0bd91a258a3e34ca3c9adae121ed7
staging: android: lowmemorykiller: Management of not killable processes

This feature allows the user to define processes and system processes
white-lists filled with the preferred process names and to not be killed
by lowmemorykiller, unless it is absolutely necessary.

This feature exposes four new lowmemorykiller parameters:
- donotkill_proc, is the flag to enable / disable this feature for the
  processes chosen by the user
- donotkill_sysproc, is the flag to enable / disable this feature for the
  system processes chosen by the user
- donotkill_proc_names, is the list of process names (comma separated)
  chosen by the user to be preserved from killing
- donotkill_sysproc_names, is the list of user system process names (comma separated)
  chosen by the user to be preserved from killing

When a the lowmemorykiller needs to free ram, it will first kill the processes
not included inside the two process name lists chosen by the user.
If there are no more standard killable processes, then it will be necessary to
kill one of the processes included inside one of the two white-lists, to
prevent system hangs, slowdowns, etc.

Change-Id: I489619b25076cdbbbfbf626826e010621fcdd23f
Build frandom as module

Change-Id: I71dcd88ea9b66f4fc3674217169f3749baa5da3f
jf: clean up and consolidate defconfigs

* regenerate commonized defconfig
* clean up the mess

Change-Id: I6895d70d3256d0d0337373919ed9f29658f30e86
Remove some unneeded defconfigs

Change-Id: I62ab5b92c52e0e2c0fd767aeaf59cea8faa2a931
remove local version string

Change-Id: I3eae4da4f0827ab82185e7c306671a57db03d923
Entropy Tweaks

Change-Id: I395b066da56cafcf89078b9080ece6247ada772d
mm/page_alloc.c: fix watermark check in __zone_watermark_ok()

The watermark check consists of two sub-checks.  The first one is:

	if (free_pages <= min + lowmem_reserve)
		return false;

The check assures that there is minimal amount of RAM in the zone.  If
CMA is used then the free_pages is reduced by the number of free pages
in CMA prior to the over-mentioned check.

	if (!(alloc_flags & ALLOC_CMA))
		free_pages -= zone_page_state(z, NR_FREE_CMA_PAGES);

This prevents the zone from being drained from pages available for
non-movable allocations.

The second check prevents the zone from getting too fragmented.

	for (o = 0; o < order; o++) {
		free_pages -= z->free_area[o].nr_free << o;
		min >>= 1;
		if (free_pages <= min)
			return false;
	}

The field z->free_area[o].nr_free is equal to the number of free pages
including free CMA pages.  Therefore the CMA pages are subtracted twice.
This may cause a false positive fail of __zone_watermark_ok() if the CMA
area gets strongly fragmented.  In such a case there are many 0-order
free pages located in CMA.  Those pages are subtracted twice therefore
they will quickly drain free_pages during the check against
fragmentation.  The test fails even though there are many free non-cma
pages in the zone.

This patch fixes this issue by subtracting CMA pages only for a purpose of
(free_pages <= min + lowmem_reserve) check.

Laura said:

  We were observing allocation failures of higher order pages (order 5 =
  128K typically) under tight memory conditions resulting in driver
  failure.  The output from the page allocation failure showed plenty of
  free pages of the appropriate order/type/zone and mostly CMA pages in
  the lower orders.

  For full disclosure, we still observed some page allocation failures
  even after applying the patch but the number was drastically reduced and
  those failures were attributed to fragmentation/other system issues.

Change-Id: Ic2c0c233993c41c630e24d71df5e12aa614588e5
CRs-Fixed:549847
Signed-off-by: Tomasz Stanislawski <t.stanislaws@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Tested-by: Laura Abbott <lauraa@codeaurora.org>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Cc: Mel Gorman <mel@csn.ul.ie>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: <stable@vger.kernel.org>	[3.7+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Git-commit: 026b08147923142e925a7d0aaa39038055ae0156
Git-repo: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git
Signed-off-by: Srinivasarao P <spathi@codeaurora.org>
mmc: core: remove the polling for BKOPS completion

The original intention of polling for BKOPS completion was to give
the card enough time to perform the BKOPS before it is runtime suspended.
But as the BKOPS completion polling was happening in a different
context, it may race with card runtime/platform suspend which is quite
difficult to fix. So instead of BKOPS polling, let the runtime suspend
get deferred if the BKOPS is running on the card. Also if BKOPS is running
when platform suspend is triggered, stop the BKOPS before suspending the
card.

Conflicts:
	drivers/mmc/core/core.c
	include/linux/mmc/card.h

CRs-Fixed: 489523
Change-Id: I21e524dc2da37c4985c210abfaca00a28049c651
Signed-off-by: Maya Erez <merez@codeaurora.org>
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
mmc: core: Fix MMC clock scaling in case of tuning failure

When the clock scaling state is changed from MMC_LOAD_LOW to
MMC_LOAD_HIGH, the clocks are first scaled up and then tuning
is performed. But in case of tuning failure, the current code
does nothing but still retain the previous clock scale stats
(state and curr_freq within struct clk_scaling). Hence, correct
it to scale down the clocks in case of tuning failure so that
clock scaling stats reflect the correct status. This also helps
proceed with data transfers at lower clock rate in such cases.

Change-Id: I7e9379d1e3ddc863132af31019604c22a42f8d59
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
mmc: core: expose HPI capability to SWITCH commands

Some of the time consuming operations such as BKOPS, SANITIZE, CACHE
flush/off use the SWITCH command (CMD6) but as these operations don't
have card specification defined timeout for completion, we may see
timeout errors if card doesn't complete the operation within the SW
defined timeout. If SW defined timeout is hit, above operations are
considered to be failed and no real recovery mechanism is implemented
after timeout.

Most of the above operations (BKOPS/SANITIZE/CACHE flush/off) can be
interrupted by sending the HPI (High Priority Interrupt) command to card
if they taking longer than expected. This change adds the base support
which will these operations to be HPIed after timeout.

Change-Id: Ibd9061525756aaae656b1ceeeaed62e04fb80cce
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
mmc: core: handle flush requests timeout

According to the eMMC 4.5 spec "Flushing a large amount of cached data may
take very unpredictably long time". Therefore the timeout for FLUSH should
be increased to prevent timeouts.

In case the timeout occurs HPI issued.

CRs-Fixed: 500874
Change-Id: Ib00d087d3fe2fa72f5eac096976d3f24b5e4966a
Signed-off-by: Maya Erez <merez@codeaurora.org>
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
board-8064-storage: fix splash screen hang

What an annoying bug...

To reproduce:
* Turn device off, unplugged
* Plug in, allow offmode charging to do its thing
* Once on the black screen, turn device on
* It'll hang on the splash screen until you pull the battery

Likely this will fix the random occurances of this too. That is yet to
be verified though.

Change-Id: Id3c419d93e7ae73c6b7d34e989483003cfece7f3