ion: invalidate cache after zero'ing buffers even if uncached

Currently, we don't invalidate the cache if we're working with uncached
buffers. However, the memory for those mappings might actually be stale
in the cache since someone else might have touched it. Just invalidate
the cache for everyone, cached or uncached.

Without this change, corruption was observed on the display due to stale
data in graphics buffers from Ion.

CRs-Fixed: 585524
Change-Id: I0037beaadfde983af15d8f45918f7798264dd3ca
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
ion: invalidate buffers before zero'ing

Currently, we invalidate the cache for buffers being zero'd *after* we
zero them. However, this is racey since a dirty cache line from an
earlier mapping could be written out to memory between the zero'ing and
the invalidation. Fix this by invalidating the cache *before* zero'ing
the buffer.

Before this change, I was seeing corruption with:

    $ cat <<EOF | ./memory_prof -e -i -
    simple_alloc,1,ION_SYSTEM_HEAP_ID,ION_FLAG_CACHED,0x100000,1MB
    simple_basic_sanity,1
    simple_profile,1
    simple_free,1
    EOF

After this change, no corruption.

CRs-Fixed: 585524
Change-Id: I1f2603604efc9be4ebf9112b06728e0aeca60ea0
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
mmc: block: Remove call to mmc_blk_set_blksize

It no longer exists.

CRs-Fixed: 561382
Change-Id: I1ca5e8f93241264ed9ffdce53067cb16476c1c66
Signed-off-by: Arve Hjønnevåg <arve@android.com>
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
mmc: core: add deferred resume support

This patch enables the deferred resume support which would
prevent initialization of the card each time the system resumes.
With this change, the resume process would only be initiated if
a request is received.

Following scenario can occur:
1. device runtime suspended, system suspend is triggered
   When resumed, the device would not be resumed until a
   request is received.
2. device is runtime active, system suspend is triggered
   When resumed, the device would be marked as BUS_NEEDS_RESUME
   and actual resume would happen, when a request is received.
   At this point, the device may also enter runtime-suspend or
   system suspend may also occur. In both the cases, since the
   device has not been resumed, it won't be suspended again.
   However, the platform device would be runtime suspended
   and resumed as before.
   It can so happen that the card is removed even before a
   request is received. In this case the device would be
   resumed and card would be removed from core layer and
   upper layers would be notified.
In case of SDIO cards, this change would not have any effect
since manual resume would be enabled for devices supporting
a block read/write commands.

CRs-Fixed: 561382
Change-Id: Id39befea109ee24864dfde0898395b972d0a1b3a
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
ARM: dts: msm: Update device tree node for audio

Rename properties and compatible strings to return to the old
naming convention.

Change-Id: Ia58df9c4084e4d570d487aff1138522d3b862a58
Signed-off-by: Kumar Gala <galak@codeaurora.org>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
ARM: dts: msm: Update device tree node for audio

Rename properties and compatible strings to return to the old
naming convention.

Change-Id: I2d090fbe336768ee7d1c41d10521c1567f26527f
Signed-off-by: Asish Bhattacharya <asishb@codeaurora.org>
Signed-off-by: Dan Trifan <jimsth@gmail.com>