reset mmc code to initial rep.
mmc: block: add mmc_blk_disable_wr_packing() disables packing mode

The function disables packing mode. Right now the only reason is
change in data direction.

Change-Id: I0f4edba3da93fde28cf47ac95754a95e411fa2af
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
mmc: do not pack random requests

Packed commands causes higher latency since the completion of each
request is sent to the upper layer upon completion of the complete
packed request.
The benefit from this feature is card dependent. Some of the card
vendors do not have any benefit from using packed commands for random
requests. In case there is no benefit in random requests packing,
it is better to disable the packing to prevent this high latency.
This patch also add the new stop packing reason to the write packing
statistics.

Change-Id: I141887dcef2ceee14848634cc27c3c85f8edc7a5
Signed-off-by: Maya Erez <merez@codeaurora.org>
mmc: core: Fix possbile memory leak

Fix possible memory leak detected by kmemleak:

unreferenced object 0xc0f80f00 (size 64):
  comm "swapper/0", pid 1, jiffies 4294937508 (age 82.980s)
  hex dump (first 32 bytes):
    6d 6d 63 30 5f 64 65 74 65 63 74 00 72 79 2e 68  mmc0_detect.ry.h
    00 07 00 00 68 77 63 61 70 2e 68 00 02 00 00 70  ....hwcap.h....p
  backtrace:
    [<c010a1fc>] __kmalloc+0x164/0x220
    [<c01e1630>] kvasprintf+0x38/0x58
    [<c01e1668>] kasprintf+0x18/0x24
    [<c02fcf60>] mmc_alloc_host+0x114/0x1b4
    [<c0311c84>] msmsdcc_probe+0xc14/0x1fd8
    [<c022b40c>] platform_drv_probe+0x14/0x18
    [<c022a144>] driver_probe_device+0x144/0x334
    [<c022a394>] __driver_attach+0x60/0x84
    [<c022884c>] bus_for_each_dev+0x4c/0x78
    [<c0229720>] bus_add_driver+0xd0/0x250
    [<c022a884>] driver_register+0x9c/0x128
    [<c00086bc>] do_one_initcall+0x90/0x160
    [<c06d1904>] kernel_init+0xe8/0x1a4
    [<c000ee4c>] kernel_thread_exit+0x0/0x8
    [<ffffffff>] 0xffffffff

Change-Id: I3b29d71463af849a072cabbe56637adf6db6d0da
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
mmc: core: remove duplicate code in mmc_rescan

If the card is removed, the wakelock has to be held for
an extended period of time to enable the user-space to
respond. The code to extend the wakelock has been
duplicated. This patch removes this duplicate code.

Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
mmc: block: fix race in deferred resume

The actual resume takes place when a request is received. In a
situation when mmcqd and qseecomd(rpmb) both try to resume the
device, a race is ensued. This is because mmcqd first resumes
the device and then claims the host. Ideally, if resume is in
progress in one context the resume in the other context should
be cancelled.
Claim the host before resuming the device in mmcqd context.

Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
[neo: Fix code format.]
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
mmc: core: Fix NULL pointer dereference issue with mmc_blk_reset()

If the mmc_hw_reset() fails, then host->card might be NULL in some
cases. Hence, check for reset errors and report it to the caller so
that the current request can be aborted and also check for host->card
before accessing it so as to prevent NULL pointer dereference issue.

Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
mmc: core: Exit clock scaling prior to removing the card

After removing the SD/MMC 'card' from the driver model we
are cancelling the pending clock scaling work which accesses
card->dev. This could cause NULL pointer issue as the card
is already removed.

CRs-Fixed: 640344
Change-Id: I8c5ee817e3f116dedf0bf4fb51eb6b70d52467b7
Signed-off-by: Pratibhasagar V <pratibha@codeaurora.org>

Conflicts:
	drivers/mmc/core/mmc.c
mmc: core: fix block request queue hang during data crc errors

When data CRC errors occur during write transactions, mmc
block layer queries the card for successful writes. If the card
reports bytes requested as bytes successfully written, the mmc
block layer will end the request with blk_end_request(). If there
is a following async request pending for execution, the request
is thrown away while handling CRC errors leading to hang in
request queue. The hang is visible when user issues a sync()
system call.

The sequence of events are as follows -

mmcqd -> fetch a request -> send it to host driver -> fetch another
request -> wait for previous request to complete -> previous request
is in error -> skip sending current request to host driver and
do error handling for previous request in error.

During the last step, after error handling is completed the mmc
block layer does not requeue the current request which is skipped
and hence the request is infinitely stuck in the driver.

Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
mmc: msm_sdcc: fix possible NULL pointer access

There is a possibility that "data" pointer may be accessed
in msmsdcc_irq() function when it's NULL. This change adds
the proper check to avoid NULL pointer dereference.

Change-Id: I95628cfb477d3e07436cffae84fa6baedc2e5905
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
mmc: msm_sdcc: don't print suspend/resume statistics in case of errors

Currently we print the time taken during SDCC host driver suspend/resume
(both platform and runtime) even if we encountered errors during it.
But sometimes, for example runtime suspend might be aborted because
actual SDCC transfer request is arrived at the same time. So printing
the statistics in such cases will not be helpful and may even cause the
confusion.

This change prints the time taken in suspend/resume only when those
operations are successfully completed.

Change-Id: I7fa5754ccddee0d90f684b05526e9434c068a0ff
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
mmc: msm_sdcc: acquire wakelock only if needed

Currently the driver assumes that when it gets an interrupt with clocks
turned OFF, that it has gotten a sdio wake up interrupt and tries to take
a wakelock. While this is not expected when sdio interrupt pin or sdio
interrupt is not defined, it looks like a situation we run into sometimes.
Ensure that the interrupt handler takes the wakelock only if the sdio
interupt or sdio interrupt pin is defined.

CRs-Fixed: 454585
Change-Id: I4842e293a5ce19a1c84a487f836f23001d69edac
Signed-off-by: Krishna Konda <kkonda@codeaurora.org>
mmc: msm_sdcc: check for pending_resume in SDCC system suspend

If system comes out of suspend, msmsdcc_pm_resume() sets the
host->pending_resume flag if the SDCC wasn't runtime suspended.
Now if the system again goes to suspend without any SDCC activity
then host->pending_resume flag will remain set which may cause the SDCC
resume to happen first and then suspend.

To avoid this unnecessary resume/suspend, make sure that pending_resume
flag is cleared before calling the msmsdcc_runtime_suspend().

CRs-Fixed: 438081
Change-Id: I2b667bec704f938a532d4780dd9b7937e2eb12c7
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
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>
Patch-mainline: v3.6
Git-commit: 6af9e96e052a6d1a760c60cb340c5a6584cb92db
Signed-off-by: Stephen Boyd <sboyd@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>
Patch-mainline: v3.7
Git-commit: 211d4fe580735bab850d31f9e4c0a62b47a38bb2
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
mmc: msm_sdcc: Disable SDCC slots at bootup if required

Add support to disable available SDCC slots at bootup controlled
via a module param with a bit mask of slots to disable.
QDSS is one use case where SDCC slot is disabled for trace output.

Example Usage:
Passing msm_sdcc.disable_slots=1 as kernel command line argument
would disable SDCC slot 1, whereas passing msm_sdcc.disable_slots=3
would disable both slots 1 and 2.

Change-Id: I65ce6f08ac86885cad4d0c672ae3174adb4ad053
Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
mmc: block: don't start new request when the card is removed

Current request can be started newly while handling the error.
But if the card is removed, it's unnecessary to restart a request.
This makes the extra error handling.

Change-Id: I0239896c69e39ef7714102b43dce81db706bdd8b
Signed-off-by: Seungwon Jeon <tgih.jun@samsung.com>
[kdorfman@codeaurora.org: modified to support packed request case]
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
Patch-mainline: v3.9?
Git-commit: 7a81902fa52f2b6f5037e167f74ebb5a41cfc7d1

Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
mmc: block: do not pack REQ_FUA request

This change will prevent packing of a request marked with REQ_FUA flag,
because it has the same semantics as REQ_FLUSH. Also packing statistics are
updated with FUA stop reason.

Change-Id: Iaad37044ec43f93e898ed0c011b0bce7b91ae13d
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
mmc: msm_sdcc: enable new reset mechanism

SDCC core version 0x2b, supports a new software reset mechanism. This reset
mechanism is useful when the core needs to be reset without having to be
reconfigured after reset.

But incidentally, this reset mechanism has a bug in the current core - one
register that is crucial to the operation that is not preserved across
reset. This register, MCI_DLL_CONFIG, needs to be preserved across
reset in order for the core to work properly in HS200 (eMMC) and SDR104
(SD protocol) modes.

Change-Id: I62e7137ae7f6489a7d5bfd93b5c8ef171e35850d
Signed-off-by: Krishna Konda <kkonda@codeaurora.org>
mmc: msm_sdcc: use DATA_PEND bit for CMD53 write operation

DATA_PEND bit (in MCI_DATA_CTL register) was designed to be used
with CMD24 (WRITE_SINGLE_BLOCK) and CMD25 (WRITE_MULTIPLE_BLOCK) to
automatically start the DPSM (Data Path State Machine) after a normal
(non-error) response is received for CMD24/CMD25. To use this feature,
MCI_DATA_CTL register should be written with the enable bit and the
pending bit asserted before ENABLE bit is set in MCI_CMD register.

Now, SDCC controller on newer chipsets like 8974/9625, supports the
DATA_PEND bit for CMD53 write operations as well.

As of now SDCC driver is not using the DATA_PEND bit for CMD53 write
which means for write operation, driver first sends the write command
to card and then waits for the CMD_RESPOND_END interrupt
and then configures ADM/BAM and DATA_CTL register (with ENABLE bit set)
in interrupt context.

Instead now driver can configure the DPSM (have to set DATA_PEND bit as
well) before configuring CPSM (Command Path State Machine) to send write
command. So basically this will be the configuration sequence if
we use DATA_PEND bit:
	1. Configure ADM/BAM.
	2. Configure DATA_CTL with both DATA_PEND and ENABLE bits set.
	3. Configure MCI_CMD register for sending the write command.

All of the above configuration will now happen at the same time in
process context.

Change-Id: I57f15ecddf0d150cdab78370eb29a622a690bd69
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>