mmc: core: Fix the HPI execution sequence

mmc_execute_hpi should send the HPI command only once, and only
if the card is in PRG state.

According to eMMC spec, the command's completion time is
not dependent on OUT_OF_INTERRUPT_TIME. Only the transition
out of PRG STATE is guarded by OUT_OF_INTERRUPT_TIME - which
is defined to begin at the end of sending the command itself.

Specify the default timeout for the actual sending of HPI
command, and then use OUT_OF_INTERRUPT_TIME to wait for
the transition out of PRG state.

Reported-by: Alex Lemberg <Alex.Lemberg@sandisk.com>
Signed-off-by: Venkatraman S <svenkatr@ti.com>
Reviewed-by: Namjae Jeon <linkinjeon@gmail.com>
Reviewed-by: Subhash Jadavani <subhashj@codeaurora.org>
Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
mmc: core: Add TRANsfer state to non-HPI state

HPI can be issued only in programming state to bring the card to
transfer state. If the card is already in transfer state, doing
a HPI is redundant.
Fix this by adding transfer state to the list of exceptions to
doing HPI and return without error.

Signed-off-by: Venkatraman S <svenkatr@ti.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
msm: kgsl: Enable HLSQ registers in snapshot when available

Reading the HLSQ registers during a GPU hang recovery might cause
the device to hang depending on the state of the HLSQ block.
Enable the HLSQ register reads when we know that they will
succeed.

Change-Id: I69f498e6f67a15328d1d41cc64c43d6c44c54bad
Signed-off-by: Carter Cooper <ccooper@codeaurora.org>
msm: Fix mutex deadlock with circular wait

tty_unregister_driver should not be called in the tty_close fn.
This creates a mutex deadlock with circular wait in the tty core.
Hence move the driver unregister and all the cleanup to a separate
worker.

Change-Id: I75d4bc6e3d4745f2565cd99eb80e35e3c926b049
CRs-fixed: 428811
Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
ASoC: wcd9310: Reset OTHR_RESET_CTR before power down

There is a missing step to clear OTHR_RESET_CTR before power down.
It could cause a glitch and power hit without it. It has to be reset.

CRs-fixed: 420142
Change-Id: I33b8114b6c913827b32d43b1a435766a22b48d84
Signed-off-by: Fred Oh <fred@codeaurora.org>
msm: pil: Support relocatable images in secure PIL

Wire up the mem_setup secure call to the secure ops for the PIL
drivers that support relocatable images. This allows the secure
verification code to know where the image has been placed into
DDR after it has been relocated.

Change-Id: Ic7616a5900f4cfa48a16899b0c7b50b5d34f6395
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
board-8064: Add necessary board support for SATA

Following changes are required in board files to
support SATA on APQ8064 CDP and MPQ8064 HRD.

1) Clocks:
    - SATA controller and PHY needs following clocks
    for correct operation:
      - AHB and AXI interface clocks
      - RX out-of-band signalling clock
      - PHY reference clock
      - PHY configuration clock

2) Regulators:
    - SATA clock generator block is powered by an external
    3.3V supply which is controlled by a PMIC MPP4 pin.
    - MPQ8064 HRD supports port multiplier (PMP) which is
    powered by PM8921 S4 regulator.

3) Platform device:
    - The MSM SATA device is added as a platform device
    with necessary resources - memory mapped i/o and irq number.

Change-Id: Ie4429e976059f2fcf306d5b8426a11e171a5b3c1
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
ata: ahci_platform: Register as hot-pluggable module

Even though AHCI controller is part of SoC in most chipsets
it is not safe to assume that AHCI device is registered before
AHCI module init is called. Register AHCI platform driver as
hot-pluggable module so that the device, driver match
can happen in any order.

Change-Id: Ifcafba0d49f01c7b31853e136e414866eca9ce99
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
msm: kgsl: Fix guilty context logic for GPU hangs

Always mark GPU contexts that have cause a GPU hang as guilty.
If the GPU context recovered successfully, still mark it as guilty.
This will inform applications that something might have
gone wrong and to take actions to ensure everything is correct.

Also, swap out any active context following a hang.  This will
ensure that any new submissions will force the context to be restored
before it is used.

CRs-fixed: 427603
CRs-fixed: 405434
Change-Id: I6b7cf2b2a680a4691f45535a147ca678a4d961f3
Signed-off-by: Carter Cooper <ccooper@codeaurora.org>
msm: kgsl: Remove duplicate code for checking timestamps

Event based as well as interruptible based timestamp checks
use the same code, they differ on if the mutex is held or not.
Separate the common code out to avoid confusion.

Change-Id: Ie2ee01d7a07ff2ba7755ab8d327796345f9ca9ea
Signed-off-by: Carter Cooper <ccooper@codeaurora.org>
msm: camera: Check for valid mem object before using it.

Add checks for validity of the mem objects for the buffer
planes before using them, to prevent any potential crashes.

Change-Id: I1221092f8c13912479c72c2bd8385b93fd7226b0
Signed-off-by: Kiran Kumar H N <hurlisal@codeaurora.org>
ASoC: msm: flush if prior and current backends rate not matching

It is found that during device switch from one backend
with one sample rate to another backend with another sample rate,
the command to QDSP6 ADM which maps audio stream session to a
particular backend would not get carried out until pending
data of audio stream session from previous backend is either
read out or flushed. This scenario occurs when application
stops providing more buffers to retrieve captured data.
Remedy is to flush upon detection of rate mismatching

Change-Id: Ia9a423315435c6c80e945d2c699c0ab509152fa6
CRs-fixed: 422205
Signed-off-by: Patrick Lai <plai@codeaurora.org>
perf: Add L2 cache PMU counters support for 8625q

Added L2 cache PMU counters support for 8625q devices.

Change-Id: I78d436b89b7d38f9188f5e6cdba83b130b47e97f
Signed-off-by: Gautam Akiwate <gakiwate@codeaurora.org>
mmc: core: Fix some driver hangs when dealing with broken devices

There are infinite loops in the mmc code that can be caused by bad
hardware.  The code will loop forever if the device never comes back
from program mode, R1_STATE_PRG, and it is not ready for data,
R1_READY_FOR_DATA.

A long timeout is added to prevent the code from looping forever.
The timeout will occur if the device never comes back from program
state or the device never becomes ready for data.

It's not clear whether the timeout will do more than log a pr_err()
and then start a fresh hang all over again.  We may need to extend
this patch later to perform some kind of reset of the device (is
that possible?) or rejection of new I/O to the device.

Change-Id: I1f3e5fddffb5134743fbfbcdef5e97803fd25fc6
Signed-off-by: Trey Ramsay <tramsay@linux.vnet.ibm.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
mmc: block: reduce the block timeout to 30 secs

After completion of block write request, MMC block driver waits for the
card to come out of the programming state. If card doesn't come out of
the programming state in 10 mins, it would be considered as error
condition and card would reinitialized. But this 10 mins is just too huge
and if card is continuously stuck in programming state for 10 mins,
mmcqd thread would take increase the CPU load significantly as we are
continuously polling for the card status (by sending status commands).

This patch reduces this timeout from 10 mins to 30 secs which is quite
reasonable for all well-behaved cards.

Change-Id: I4e8eaf29c836a81419220f312ee867b0dd5cccc7
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
mm: show migration types in show_mem

This is useful to diagnose the reason for page allocation failure for
cases where there appear to be several free pages.

Example, with this alloc_pages(GFP_ATOMIC) failure:

 swapper/0: page allocation failure: order:0, mode:0x0
 ...
 Mem-info:
 Normal per-cpu:
 CPU    0: hi:   90, btch:  15 usd:  48
 CPU    1: hi:   90, btch:  15 usd:  21
 active_anon:0 inactive_anon:0 isolated_anon:0
  active_file:0 inactive_file:84 isolated_file:0
  unevictable:0 dirty:0 writeback:0 unstable:0
  free:4026 slab_reclaimable:75 slab_unreclaimable:484
  mapped:0 shmem:0 pagetables:0 bounce:0
 Normal free:16104kB min:2296kB low:2868kB high:3444kB active_anon:0kB
 inactive_anon:0kB active_file:0kB inactive_file:336kB unevictable:0kB
 isolated(anon):0kB isolated(file):0kB present:331776kB mlocked:0kB
 dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:300kB
 slab_unreclaimable:1936kB kernel_stack:328kB pagetables:0kB unstable:0kB
 bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
 lowmem_reserve[]: 0 0

Before the patch, it's hard (for me, at least) to say why all these free
chunks weren't considered for allocation:

 Normal: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 1*256kB 1*512kB
 1*1024kB 1*2048kB 3*4096kB = 16128kB

After the patch, it's obvious that the reason is that all of these are
in the MIGRATE_CMA (C) freelist:

 Normal: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 1*256kB (C) 1*512kB
 (C) 1*1024kB (C) 1*2048kB (C) 3*4096kB (C) = 16128kB

Change-Id: Ic5fe77d762e0c03715bfb917774e7c4f03ac43f5
Signed-off-by: Rabin Vincent <rabin.vincent@stericsson.com>
Cc: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
mm: cma: on movable allocations try MIGRATE_CMA first

It has been observed that system tends to keep a lot of CMA free pages
even in very high memory pressure use cases.  The CMA fallback for
movable pages is used very rarely, only when system is completely
pruned from MOVABLE pages.  This means that the out-of-memory is
triggered for unmovable allocations even when there are many CMA pages
available.  This problem was not observed previously since movable
pages were used as a fallback for unmovable allocations.

To avoid such situation this commit changes the allocation order so
that on movable allocations the MIGRATE_CMA pageblocks are used first.

This change means that the MIGRATE_CMA can be removed from fallback
path of the MIGRATE_MOVABLE type.  This means that the
__rmqueue_fallback() function will never deal with CMA pages and thus
all the checks around MIGRATE_CMA can be removed from that function.

Change-Id: Ie13312d62a6af12d7aa78b4283ed25535a6d49fd
CRs-Fixed: 435287
Signed-off-by: Michal Nazarewicz <mina86@mina86.com>
Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
power: qpnp-charger: change USB debounce time to 20ms

To avoid spurious USBIN_VALID interrupts increase the
debounce time on the USB peripheral to 20ms.

CRs-Fixed: 433617
Change-Id: I312c8643709bc4dec3e5924b6108e934cb528680
Signed-off-by: David Keitel <dkeitel@codeaurora.org>
crypto: Use scatterwalk APIs in crypto

sg_next() may find wrong scatter-gather buffer in crypto subsystem,
and this causes a kernel crash. scatterwalk_sg_next() should be used
instead in crypto related drivers.

Change-Id: Ibb454bc8a8b2c0318e55cd12ba3e4ca2f3647e36
Acked-by: Ho Lee <holee@qti.qualcomm.com>
Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
gpu: ion: Add flag for forcing contiguous allocations

Previously, a parameter was added to secure heaps to only
allow secure allocations. Some clients still require
non-secure contiguous allocations even though the SMMU is
supported. Add support for those clients to force contiguous
allocations to go through.

Change-Id: I10493bd2fa6c58bf26f01ee0af43055e3df92c54
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>