Revert "fb_earlysuspend: merging patches from LGE"

This reverts commit 30b3047f0c677cb2dabc459d9043b6677ed1179e.

...causing an permanent re-activation of RPC kernel wakelocks.
msm: rpc: invalidate data structures during close

When device powers down, RPC Router close can get called from both the
reboot notifier and from the platform driver remove resulting in an
access-after-free bug.

Invalidate internal data structures and check for NULL to gracefully
handle multiple close operations.

CRs-Fixed: 394129
Change-Id: I9d16afdef4962e48e2d45e9523441744b6611b00
Signed-off-by: Arun Kumar Neelakantam <aneela@codeaurora.org>
Signed-off-by: Eric Holmberg <eholmber@codeaurora.org>
msm: rpc: add shutdown and restart handler for rpc

Add shutdown and restart handler for rpcrouter. The
shutdown handler take care of calling the
msm_rpcrouter_close function with a pre defined
priority. PM no longer handle rpc close in the shutdown/reboot
sequence.

CRs-fixed: 396641
Change-Id: I83d4bbe759b573cb0d9d9b2c8d3d1d907ec297d5
Signed-off-by: Arun Kumar Neelakantam <aneela@codeaurora.org>
Signed-off-by: Angshuman Sarkar <angshuman@codeaurora.org>
msm: rpc: Fix uninitialized union in rpc router code

Initialize the rr_control_msg union to prevent the local users to obtain
sensitive information from kernel memory.

CRs-Fixed: 515623
Change-Id: I778e6544fab22a2e2d87acaa7192e063dae4fbc7
Signed-off-by: FNU Ramendra <rramendr@codeaurora.org>
msm: rpc: Fix uninitialized union in rpc router close function

Initialize the rr_control_msg union to prevent the local users from
obtaining sensitive information from stack  memory in msm_rpcrouter_close
function.

CRs-Fixed: 515623
Change-Id: Ife87010eb81e8840c9b1bf5d8aeb941c90020eac
Signed-off-by: FNU Ramendra <rramendr@codeaurora.org>
msm: rpc: remove huawei debug code

Signed-off-by: moddingg33k <moddingg33k@t-online.de>
Merge branch 'CAF/msm-rpc' into synopsis-dev
remove defconfig(s)
config: various updates

- disabled some debugging related settings

- enabled UHID driver

Signed-off-by: moddingg33k <moddingg33k@t-online.de>
msm_fb: fix compile error

...due of previous config changes

Signed-off-by: moddingg33k <moddingg33k@t-online.de>
mmc: core: Don't cancel detect work during MMC suspend

When MMC host is suspending the cancellation of the MMC detect
work is in progress. And mmc_rescan() which had triggered for
SD card is blocked since mmcqd/1 has acquired the host lock.
The mmcqd/1 is waiting to proceed for the card status check.
Meanwhile, a write request is received on eMMC but it cannot
proceed as it is waiting for the ongoing runtime suspend to finish.

"kworker/0:1"
----
-000|need_resched()
-001|schedule_timeout(timeout = 2147483647)
-002|wait_for_common(x = 0xD9391E90, ?, state = 2, iowait = 0)
-003|flush_workqueue(wq = 0xD92DCA80)
-004|mmc_suspend_host(host = 0xD8B20000)
-005|msmsdcc_runtime_suspend(dev = 0xC08B0598)
-006|pm_generic_runtime_suspend(?)
-007|__rpm_callback(cb = 0xC02F1BD8, dev = 0xC08B0598)
-008|rpm_suspend(dev = 0xC08B0598, rpmflags = 2)
-009|pm_runtime_work(work = 0xC08B065C)
-010|process_one_work(worker = 0xD9367F40, work = 0xC08B065C)
-011|worker_thread(__worker = 0xD9367F40)
-012|kthread(_create = 0xD924FF18)
-013|kernel_thread_exit(asm)
 ---|end of frame
    |

"kworker/u:4"
----
-000|need_resched()
-001|__mmc_claim_host(host = 0xD8B21000, abort = 0x0)
-002|mmc_sd_detect(host = 0xD8B21000)
-003|mmc_rescan(work = 0xD8B212A0)
-004|process_one_work(worker = 0xCDB12440, work = 0xD8B212A0)
-005|worker_thread(__worker = 0xCDB12440)
-006|kthread(_create = 0xD8BC7F18)
-007|kernel_thread_exit(asm)
 ---|end of frame
    |

mmcqd/1 (running)
----
-000|need_resched()
-001|schedule_timeout(timeout = 2147483647)
-002|io_schedule_timeout(timeout = 2147483647)
-003|wait_for_common(x = 0xD8633E2C, ?, state = 2, iowait = 1)
-004|mmc_wait_for_req_done(host = 0xD8B21000, mrq = 0xD8633E1C)
-005|mmc_wait_for_cmd(host = 0xD8B21000, cmd = 0xD8633E50, retries = 5)
-006|get_card_status(card = 0xD8D8B800, status = 0xD8633EA4, retries = 5)
-007|mmc_blk_err_check(card = 0xD8D8B800, areq = 0xD8624440)
-008|mmc_start_req(host = 0xD8B21000, areq = 0x0, error = 0xD8633F4C)
-009|mmc_blk_issue_rw_rq(mq = 0xD8624008, ?)
-010|mmc_blk_issue_rq(mq = 0xD8624008, req = 0x0)
-011|mmc_queue_thread(d = 0xD8624008)
-012|kthread(_create = 0xD9397D80)
-013|kernel_thread_exit(asm)
 ---|end of frame
    |

mmcqd/0
----
-000|need_resched()
-001|rpm_resume(dev = 0xC08B0598, rpmflags = 4)
-002|__pm_runtime_resume(dev = 0xC08B0598, rpmflags = 4)
-003|msmsdcc_enable(mmc = 0xD8B20000)
-004|__mmc_claim_host(host = 0xD8B20000, abort = 0x0)
-005|mmc_blk_issue_rq(mq = 0xD8C43008, req = 0xC52C9798)
-006|mmc_queue_thread(d = 0xD8C43008)
-007|kthread(_create = 0xD9397D80)
-008|kernel_thread_exit(asm)
 ---|end of frame
    |

So remove the cancellation of the detect work for the
MMC suspend to proceed and avoid this deadlock.

Change-Id: Id79d6b81e992b08039d639b1c0f6c2eb4a79df62
Signed-off-by: Pratibhasagar V <pratibha@codeaurora.org>
mmc: card: abort the suspend if the card is busy

mmc_blk_suspend() is triggered when system is going into suspend which
then waits for the mmcqd thread (which processes active MMC transfer
requests) to complete all queued transfer requests but if mmcqd has
multiple requests to be processed at this point, mmc_blk_suspend() may
very well sleep for duration longer than DPM (Device Power Management)
timeout (currently 12 sec) causing the DPM timeout bug.

To fix this issue, mmc_blk_suspend() checks if there are any more pending
MMC requests in progress or not and if there are any, it returns error
which should abort the ongoing system suspend.

CRs-Fixed: 439192
Change-Id: I51a31cf43c8da4944617d1c4441a27cc6577926f
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
mmc: core: reinitalize the eMMC card always on resume

Some eMMC cards dont come out of sleep when running in HS200 mode and
so to ensure that the eMMC card is reliably brought out of sleep.

Signed-off-by: Krishna Konda <kkonda@codeaurora.org>
(cherry picked from commit 07d1f38c55bf5c17ecfd926b92ddb167907b584e)

Change-Id: Ief71ab3324723e03cbe6bc0b66a81b7d8bc203d9
Signed-off-by: Gopal Goberu <ggober@codeaurora.org>
msm-camera: Handling multiple camera open calls properly

Handling locks properly while multiple msm_open calls occured.

CRs-Fixed:453696

Change-Id: Ia740045e97026c33d2be4cc40d22ccb486562c40
Signed-off-by: Katta Santhisindhu <kattas@codeaurora.org>
power: msm-battery: Report USB WALL charger as MAINS supply-type

USB wall charger falls under the category of a dedicated wall
charger. Categorize it as a type of MAINS power supply.

CRs-Fixed: 429508
Change-Id: I1ba3ace8836aa4b094b8454fb78e24ea66c826ff
Signed-off-by: Anirudh Ghayal <aghayal@codeaurora.org>

[moddingg33k: adapted changes to huawei's battery driver]
Signed-off-by: moddingg33k <moddingg33k@t-online.de>
msm: audio: qdsp5: Fix to Update acdb_audpp_entry in device switch

-Issue: Parameters of acdb_audpp_entry like, AUDIO_NS_TX, AUDIO_AGC_TX,
AUDIO_IIR_TX is not updating when device switched during recording.
-Incorrect audio session information getting updated to acdb driver
during audio preproc enable call back.
-Fix: By updating the value of acdb_data.audrec_applied variable when
device got changed, acdb_audpp_entry's parameters are getting update.
-By updating audio recording session before calling audio preproc enable.

Change-Id: I224d626ccce0f91eccc29890d870ff98d7fb05ce
CRs-Fixed: 509455
Signed-off-by: Nitesh Bhardwaj <nbhard@codeaurora.org>
mm: vmscan: do not keep kswapd looping forever due to individual uncompactable zones

When a zone meets its high watermark and is compactable in case of
higher order allocations, it contributes to the percentage of the node's
memory that is considered balanced.

This requirement, that a node be only partially balanced, came about
when kswapd was desparately trying to balance tiny zones when all bigger
zones in the node had plenty of free memory.  Arguably, the same should
apply to compaction: if a significant part of the node is balanced
enough to run compaction, do not get hung up on that tiny zone that
might never get in shape.

When the compaction logic in kswapd is reached, we know that at least
25% of the node's memory is balanced properly for compaction (see
zone_balanced and pgdat_balanced).  Remove the individual zone checks
that restart the kswapd cycle.

Otherwise, we may observe more endless looping in kswapd where the
compaction code loops back to reclaim because of a single zone and
reclaim does nothing because the node is considered balanced overall.

See for example

  https://bugzilla.redhat.com/show_bug.cgi?id=866988

Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Reported-and-tested-by: Thorsten Leemhuis <fedora@leemhuis.info>
Reported-by: Jiri Slaby <jslaby@suse.cz>
Tested-by: John Ellson <john.ellson@comcast.net>
Tested-by: Zdenek Kabelac <zkabelac@redhat.com>
Tested-by: Bruno Wolff III <bruno@wolff.to>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Conflicts:

	mm/vmscan.c

Change-Id: I9c8f180466fea814c3038fa019f317799ddc0bcb
Signed-off-by: Chintan Pandya <cpandya@codeaurora.org>
mm: vmscan: fix endless loop in kswapd balancing

Kswapd does not in all places have the same criteria for a balanced
zone.  Zones are only being reclaimed when their high watermark is
breached, but compaction checks loop over the zonelist again when the
zone does not meet the low watermark plus two times the size of the
allocation.  This gets kswapd stuck in an endless loop over a small
zone, like the DMA zone, where the high watermark is smaller than the
compaction requirement.

Add a function, zone_balanced(), that checks the watermark, and, for
higher order allocations, if compaction has enough free memory.  Then
use it uniformly to check for balanced zones.

This makes sure that when the compaction watermark is not met, at least
reclaim happens and progress is made - or the zone is declared
unreclaimable at some point and skipped entirely.

Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Reported-by: George Spelvin <linux@horizon.com>
Reported-by: Johannes Hirte <johannes.hirte@fem.tu-ilmenau.de>
Reported-by: Tomas Racek <tracek@redhat.com>
Tested-by: Johannes Hirte <johannes.hirte@fem.tu-ilmenau.de>
Reviewed-by: Rik van Riel <riel@redhat.com>
Cc: Mel Gorman <mel@csn.ul.ie>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Conflicts:

	mm/vmscan.c

Change-Id: I17a375f356189bde63406e2127153287208157a8
Signed-off-by: Chintan Pandya <cpandya@codeaurora.org>
msm: Fix the flush sync between client and dma driver

Flush is not properly handled in present dma driver, it is not deleting
previous commands once we get flush command from client.Delete previous
commands if we get forceful flush or else append flush to latest cmd.

Change-Id: I9a78f98b6e59c558ed52b12c18606161cb461b5c
Signed-off-by: Ravi Kumar V <kumarrav@codeaurora.org>
msm_fb: Fine tune the porch value calculations for DSI panels

Fine tune the porch calculations to be programmed in DSI
controller and MDP timing generator for the DSI video mode
panels. This helps in programming the proper porch values
specific to the DSI panel used.

Change-Id: I97be9a67edff2c8703876f6b9b01f15cbdd6e620
Signed-off-by: Padmanabhan Komanduru <pkomandu@codeaurora.org>