The CDR is supposed to be enabled only for read commands but
since there is no way it can be done in CQ, disable it completely
in CQ mode.
The CDR gets enabled by default whenever tuning is done in legacy
mode. Hence, make sure to disable it when CQ is enabled or when
CQ is unhalted.
Also note that CDR plays a role only in these bus speed modes -
HS200 and HS400 with enhanced strobe disabled.
Change-Id: Ie3917ac9b573dfef514f82e5073d1c480cd9a71d
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Add the functionality to disable CDR to
sdhci_cmdq_set_transfer_params() so that CQ driver can
use it appropriately.
Change-Id: I5182b48523e7f9511265fa557433b88224318a23
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
The scaling logic for HS400 is triggered when the card timing
mode is HS400 or when the clock rate is MMC_HS200_MAX_DTR. But
this is the same rate used in HS200 mode as well. Due to this,
in HS200 mode also, the card enters into the scaling logic meant
for HS400 which is not correct.
Correct this logic by checking the card timing in addition to the
clock rate in HS400 clock scaling logic.
Change-Id: If6261c0e42178d331184ac605c192d48a76e1e29
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
There are issues with ADMA when used with ICE enabled for tuning
commands. As a workaround, use PIO mode for these commands by
enabling quirk SDHCI_QUIRK2_USE_PIO_FOR_EMMC_TUNING .
Change-Id: I8dbec823938525af90fb990db1bb4b325ee23cba
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Some controllers have an issue using ADMA for tuning commands.
Add a quirk - SDHCI_QUIRK2_USE_PIO_FOR_EMMC_TUNING to use PIO
mode for tuning commands on those host controllers.
Change-Id: Id9625167d7e235fb3a20a6193889c1654b5c0cd8
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
[subhashj@codeaurora.org: fixed trivial merge conflicts]
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Some controllers need SW to compare the data received
from the card for a tuning command. Enable this quirk -
SDHCI_QUIRK2_NON_STANDARD_TUNING for sdhci msm host
controller.
Change-Id: Id6f6230520db1ad018c883cb639fe66b4b86c70c
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Some controllers need SW to compare the data received
from the card for a tuning command. Add a quirk for
such non standard controllers so that they can read
the data from the controller using ADMA/PIO and do the
tuning sequence from SW to determine the appropriate phase.
Change-Id: I15edfdf0442e3ac678c70df29482b3304cf1215a
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
[subhashj@codeaurora.org: fixed trivial merge conflicts]
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
This is needed to set the dma mode for CQ transfers. The dma mode
may be changed by the commands sent in legacy mode (like tuning
which uses FIFO mode).
Change-Id: Idaa2cb0c7712846f6827272caefc112b127ef818
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
[subhashj@codeaurora.org: fixed trivial merge conflicts]
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Some of the transfer parameters like DMA mode will be changed
only when CQ is in HALT state to send some legacy commands like
tuning etc.
Also, fix a typo with set_transfer_params() host op.
Change-Id: I3a9856e0d60ce6a9cc1727cd8ccd10ef33bb707c
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Data CRC errors are observed for the data commands that are
sent immediately after tuning in HS200 mode with CQ enabled but
in HALT state. This is because tuning commands change the block
size to 128 bytes from the default 512 bytes.
Change-Id: I9657b16954b54c491fa19f9d82d9141edf45e0ef
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
The bkops status is indicated by the bit 0 and 1 of the
246th byte of the ext_csd register.
The current code doesn't ignore the rest of the byte.
Fix this by extracting the bit 0 and 1 only
for the current bkops urgency.
The exception level is defined by the least significant
nibble of 54th byte in the ext_csd register. The current
code doesn't ignore the rest of the byte.
Fix this by extracting the nibble(LSB) for exception status.
Change-Id: Ic90fe26a676ae7dd2063e17bc3771db83605f4dc
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
[subhashj@codeaurora.org: fixed trivial merge conflicts]
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
We need to add mmc_host_clk_hold/release pair before caching
host->ios. Since it may so happen that the clks are gated
while caching and thus in next CMD5 awake, changing clk back to
cached_ios->clk might give NOC error.
Change-Id: I32b8c1bbbd67b4daadaa85c3c01beab8ff1b7cb2
Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>
Fix the below reported issues by source code analyzer.
1) Pointer 'ext_csd' returned from call to function 'mmc_get_ext_csd'
may be NULL and will be dereferenced at ext_csd[EXT_CSD_CMDQ] in
mmc_test_awake_ext_csd(), causing NUll pointer derefernce.
2) Array 'sdhci_slot' of size 2 may use index value(s) -1 as below,
when ret = 0.
sdhci_slot[ret-1] = msm_host;
3) Variable 'host->lock' locked ,And was not unlocked when below
condition occurs in sdhci_irq().
if (!mmc_card_and_host_support_async_int(host->mmc))
return IRQ_NONE;
CRs-Fixed: 1000387
Change-Id: Iec6ecef1bf940e720c871be58b265394904f0cf1
Signed-off-by: Pavan Anamula <pavana@codeaurora.org>
This reverts 'commit d49beb9a2a71 ("mmc: sdhci: Panic
after SDHC registers")'. As CMDQ is quite stable now,
removing a BUG_ON which was added internally to crash
system on error.
Change-Id: Ie0c11743fb781e765c926e3408b87eaf94dc2eb6
Signed-off-by: Sayali Lokhande <sayalil@codeaurora.org>
[subhashj@codeaurora.org: fixed trivial merge conflicts]
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
The scaling down sequence requires the clock to be set
after selecting the corresponding bus-speed mode in the
controller.
The scaling up to HS400 requires the timing and clock to
be set to legacy.
Without the above configuration, bus-width switch fails,
further leading to CRC errors.
Change-Id: If502f28e19924264dfb99d76f6881d3167f56a05
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Pavan Anamula <pavana@codeaurora.org>
Make sure the card is present before enabling/disabling clock scaling,
to prevent NULL pointer access.
Change-Id: I1d683c4202ce34edeb6cb36d9713e226bb6f43d7
Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
The commit '6e2df8c0e' incorrectly sets this capability.
This needs to be set only if the host is capable of disabling
both vcc and vccq. For SDHCI MSM host controllers only vcc
is disabled during suspend. Hence, remove this capability
for MSM hosts.
Change-Id: I69f9dacaa042e9f9a0bc4ed886f97c5c4a3b9791
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
This change fixes few compilations issues seen
if we enable the SDHCi MSM driver.
Change-Id: Iaa556e189cbbc6a7f9c3d485e94a43cb21a968a7
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
msm-3.18 kernel had our own implementation of 64-bit ADMA support but
upstream kernel have now added its own implementation of 64-bit ADMA
support hence this patch removes some of the remaining variables from
our implementation.
Change-Id: I3ea8e9e498b25b75fb1f5ccc4ffe5f6986cd564a
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
This patch adds check to enable the 64-bit DMA only if the chipset
supports the same.
Change-Id: I5dbe6f91d5e530b289f4cf395ae7b673acd85fcf
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
SDHCI_USE_ADMA_64BIT flag was being used by msm-3.18 kernel but now that
upstream sdhci driver has introduced support for 64-bit ADMA, it defined
new flag SDHCI_USE_64_BIT_DMA. Hence replace all the SDHCI_USE_ADMA_64BIT
references with SDHCI_USE_64_BIT_DMA flag.
Change-Id: I6a1e426c156d4ddb92bba00b5ec0cfb156d9550b
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Change "man_bkops_en" to "bkops_en" to hold the status of
both manual and auto bkops.
Change-Id: I60029bae67cebb2c91147ad741b96f4caed9c1d9
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
This reverts commit 82ccc79fd3c4456b7b344db4576e874d324c6243.
Similar change is already present and this one just added the
duplicate code hence revert it.
Change-Id: Ia96ebe80e4fb7987f9e98e42575ff2ebe153dd23
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
If zero length ADMA descriptor with "Tran" attribute is queued to ADMA
descriptor table then host controller ADMA engine might get stuck.
Currently we are seeing zero length descriptor getting queued in for
SDIO transactions:
SDHCi driver requires that any data buffer address should be 4-byte
aligned for 32-bit ADMA and 8-bytes aligned for 64-bit ADMA. For 64-bit
ADMA, it forces 8-byte alignment for any data buffer addresses. This
aligment requirement is not an issue with eMMC/SD cards as their
transactions are always in multiple of 512-bytes (block size) and hence
sdhci driver would always get the data buffers whose address is properly
aligned.
SDIO can have transactions less than 512-bytes. Hence its quite possible
for driver to receives data buffer addresses which are not properly
aligned. And if they are not aligned, SDHCi driver bounces the non-aligned
bytes to pre-allocated aligned buffer until the rest of the data buffer
becomes aligned. But this logic has a bug where after moving the
non-aligned number of bytes to aligned buffer, it assumes that we will
always be left with non-zero number of bytes in original data buffer and
hence driver ends up queuing one more descriptor which can be of zero
length.
Fix this by checking for the remaining data length before queuing up the
next descriptor.
Change-Id: I7af77b2a2661c00f2b1da47953717b1506bdba83
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
[subhashj@codeaurora.org: fixed merge conflicts]
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
There's a deadlock between runtime-suspend and devfreq monitor.
runtime-suspend context:
[<ffffffc00008771c>] __switch_to+0x7c
[<ffffffc000e0212c>] __schedule+0x53c
[<ffffffc000e02404>] schedule+0x74
[<ffffffc000e02770>] schedule_preempt_disabled+0x14
[<ffffffc000e04c8c>] __mutex_lock_slowpath+0x1dc
[<ffffffc000e04e54>] mutex_lock+0x2c
[<ffffffc000acfc98>] devfreq_monitor_suspend+0x1c
[<ffffffc000ad160c>] devfreq_simple_ondemand_handler+0x4c
[<ffffffc000acf8b4>] devfreq_suspend_device+0x2c
[<ffffffc0008fa5a0>] mmc_suspend_clk_scaling+0xac
[<ffffffc000900398>] _mmc_suspend.isra.11+0x38
[<ffffffc000900798>] mmc_runtime_suspend+0x1cc
[<ffffffc0008fd4c4>] mmc_runtime_suspend+0x18
[<ffffffc000579c98>] __rpm_callback+0x40
[<ffffffc000579d0c>] rpm_callback+0x40
[<ffffffc00057a338>] rpm_suspend+0x25c
In the above stack, runtime-suspend is waiting on the devfreq mutex.
In the below stack, the mutex has been acquired and since the device
power state is DEV_SUSPENDING, devfreq is waiting for the device to
resume, thus causing a deadlock.
[<ffffffc000e02404>] schedule+0x74
[<ffffffc00057abdc>] rpm_resume+0x264
[<ffffffc00057ae80>] __pm_runtime_resume+0x70
[<ffffffc0008f880c>] mmc_get_card+0x1c
[<ffffffc0008f9d08>] mmc_devfreq_set_target+0x154
[<ffffffc000acf9d0>] update_devfreq+0xd0
[<ffffffc000acfb38>] devfreq_monitor+0x2c
Fix this by not waiting for device to resume in devfreq. The suspend would
ensure that this devfreq monitor thread is suspended before suspending the
device.
Change-Id: Ic0e89becbfded35c90c4061f0fe03d61125f66d5
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
Hynix emmc cards are causing read data timeout.
Increase timeout value to max of 4sec and add card
quirk for all Hynix emmc cards.
Change-Id: I78637dc787964ec5cafe297587d6a12ecf1d31c6
Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>
The commit '77dacd' misses to add mmc_host_clk_release() in the
completion path of a CQ request i.e., in mmc_blk_cmdq_complete_rq().
Hence, the reference counter of clocks (host->clk_requests) never
becomes 0, preventing the clocks from gating. However, the clocks
are still turned off through other power management features such as
runtime/system suspend.
Change-Id: I0032861b1e5218bdf3c5bed664869c708ce50148
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Some devices require long BKOPs time in order to provide high performance.
In the current solution, the host disables auto BKOPs or stops manual BKOPs
in runtime suspend, regardless of the device need for BKOPs.
This patch adds a check for device BKOPs status and defers suspend in case
when BKOPs need.
CRs-Fixed: 979630
Change-Id: Ib38d1ce58e4195d4969e9a367b5738c8e598d0ba
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
[subhashj@codeaurora.org: fixed merge conflicts]
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
On runtime suspend flow, AUTO_EN must be turned off (see eMMC 5.1
specification 6.6.28). During runtime resume, it should be restored again.
When partial card initialization flow is used on runtime resume (instead of
full card initialization), this flow should restore AUTO_EN bit if needed.
CRs-Fixed: 979630
Change-Id: I4ac3b7c45fdba36d014f4c88cb704bbf36011d59
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
Remove the runtime idle state. It was introduced by
217cf95511d23f703d0e7e597d3132739739654b
Instead of checking BKOPS logic in the runtime idle state, all relevant
logic should be performed in runtime suspend callback.
CRs-Fixed: 979630
Change-Id: Iaf0d8326c0e3fd6507b075339f2cc87ae1bdf6b2
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
[subhashj@codeaurora.org: fixed trivial merge conflicts]
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
The mmc host needs to perform at its peak when clock scaling
is disabled, hence switch the frequency to max.
CRs-fixed: 981387
Change-Id: Ie959b8e565ee2dad53cdd9d913bcb8696519d7ca
Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
CMDQ shutdown path calls blk_cleanup_queue, which changes queue_lock
from driver lock to it's original request_queue lock.
Hence during above shutdown process if below sequence is exercised
as well then may see below spinlock bug.
a) Some process say iozoneA has already acquired queue_lock (which
is md->lock).
b) adb reboot has been issued and CMDQ driver has completed calling
blk_cleanup_queue which switches the queue_lock from md->lock to
q->__queue_lock.
c) ProcessA tries to release queue_lock but finds an unbalance that
the lock is already released
Hence remove blk_cleanup_queue and instead make sure there are no
active_reqs in flight by mmccmdqd before this kthread is exited.
Callstack:
<6> BUG: spinlock already unlocked on CPU#6, iozone/4391
<6> lock: 0xffffffc06ab8be80, .magic: dead4ead,
.owner: <none>/-1, .owner_cpu: -1
[ffffffc0420e3b28] __delay at ffffffc00031a328
[ffffffc0420e3b38] __const_udelay at ffffffc00031a304
[ffffffc0420e3b58] msm_trigger_wdog_bite at ffffffc0004476cc
[ffffffc0420e3b68] spin_bug at ffffffc0000e4554
[ffffffc0420e3b98] do_raw_spin_unlock at ffffffc0000e47a0
[ffffffc0420e3bc8] _raw_spin_unlock_irq at ffffffc000db3ee0
[ffffffc0420e3be8] blk_queue_bio at ffffffc0002ff1e4
[ffffffc0420e3bf8] generic_make_request at ffffffc0002fd210
[ffffffc0420e3c58] submit_bio at ffffffc0002fd328
[ffffffc0420e3ca8] submit_bio_wait at ffffffc0002f5768
[ffffffc0420e3d00] compat_sys_call_table at ffffffc00008e000
[ffffffc0420e3d18] submit_bio_wait at ffffffc0002f574c
[ffffffc0420e3d38] __blkdev_issue_flush at ffffffc00030043c
[ffffffc0420e3da8] blkdev_issue_flush at ffffffc000300494
[ffffffc0420e3dd8] ext4_sync_fs at ffffffc0002597a4
CRs-fixed: 953541
Change-Id: I769cc25c14b6d873f64a898d6b73f33cc59d9c5d
Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>
Due to recent DDR52 lower bus speed mode in clock scaling,
there is a mismatch between the clock frequencies used by
the devfreq framework and the MMC driver. Due to this, SDCC
clock is sometimes running at DDR25 and ICE clock is running
at 100MHz causing the power regression. Fix this mismatch by
initializing the frequencies properly during MMC resume based
on the current ios.clock.
CRs-Fixed: 974940
Change-Id: I09fe888d0fbd1fde3f6a6f32806315ddbb5bf6e1
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Some eMMC vendors violate eMMC 5.0 spec and set REL_WR_SEC_C
register to 0x10 to indicate the ability of RPMB throughput
improvement thus lead to failure when TZ module write data to
RPMB partition. This change will check bit[4] of EXT_CSD[166]
and if it is not set then change value of REL_WR_SEC_C to 0x1
directly ignoring value of EXT_CSD[222].
CRs-Fixed: 866059
Change-Id: Ibd12c94ad691eca1fa3ea2049b750a6e98178678
Signed-off-by: xiaonian <xiaonian@codeaurora.org>
Signed-off-by: Pavan Anamula <pavana@codeaurora.org>
Some controllers doesn't have any limitation on the memory
it can address. Hence, the bounce limit parameter must be taken
based on the device dma_mask.
Currently it is set to BLK_BOUNCE_HIGH, which may cause bouncing
of memory higher than this limit. Use dma_mask as the limit for
queue bounce parameter to avoid this unncessary memory bouncing
in the block layer.
CRs-Fixed: 964435
Change-Id: I0955438a540ca9adf5bcd3a0dbf9201a5ef456a5
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
For any commands, that are sent during tuning sequence
CRC errors are expected. But if SDHCI_NEEDS_RETUNING flag
is set, then it will recursively do the tuning and gets
stuck in tuning. Fix this by not allowing the re-tuning to
happen while it is already in tuning process.
Change-Id: I9cc39f03a01c34f2f5639d4c20776fd575c25231
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Make sure we don't peek the block layer queue and act on it when
block queue is stopped. The block queue will be stopped when mmc
block is suspended, wait till it is properly resumed before pulling
new requests.
Change-Id: Ifc369687c13dae904271e8f92d3604edbd667d82
Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
It seems that when we are configuring sdiowakeup_irq, we are
receiving a spurious interrupt which sets sdio_pending_processing
state to true.
Now, if the sdio card is physically connected but wifi not enabled
in that case suspend functionality will be broken sdhci_msm_suspend_noirq
will return -EBUSY if sdio_pending_processing is set to true.
Thus fix it by setting this flag to false after we have disabled
sdiowakeup_irq.
CRs-Fixed: 957968
Change-Id: I755b0b5602345ad6bf557c6055b9057012de0797
Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Add a check on cmdq_host->ops to avoid NULL pointer
dereference, if sdhci_dumpregs is called before
initializing cmdq_host->ops structure.
Change-Id: Idd1794e162c7a53cc63504e15e6e490481f104a3
Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>
Change mdelay to udelay to fix 100sec waiting timeout
bug in sdhci_reset. sdhci_reset is intended to only
wait for 100msec.
Change-Id: I6b5c9b10daf7cd8a7faf16ac6bdb09c5079a39e9
Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>
If during early boot register dump is called, then
there could be a NULL pointer dereference since mmc_host
structure might not be populated with cq_host info.
Thus fix this by using sdhci_host to get cq_host structure info
in sdhci_msm_cmdq_dump_debug_ram.
Change-Id: Ieaca7887001daabd4a6a0b05f7b0048dc11bbeee
Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>
cmdq_halt and cmdq_disable gets called from cmdq_irq in case
of error. Thus add cmdq_disable_nosync and unhalt support
in cmdq_halt_poll which can be called from irq context.
Change-Id: I172e0e29a5584f02dd96c8af5ea1b97dc8c46083
Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>
No need to call post_req if it's a DCMD request
completion.
Change-Id: Id11165967e316b1e556aaeb6d67bd18844cee6e1
Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>
In case of error, software may power cycle/reset both
controller and card. Thus even if auto bkops is enabled,
mmc_set_ios can be used to power-off/power-on.
Fix this by removing this condition from mmc_set_ios.
Change-Id: I88a610ecbcc4036ac8ba99bc54706243b40db391
Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>
Currently cmdq discard requests are not using same
softirq completion path as other cmdq request. So there
is no way to detect any error and handle it in case
of error of DCMD requests.
Make cmdq discard requests use blk_complete_requests
which complete via softirq completion path.
Change-Id: I1e03c81bc6fee8266cf1c86bada015e548770d7a
Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>
This does following:
1. Adds support to handle multiple cmdq software requests timeout.
Currently we schedule error handling work for the first timedout
request. We requeue all pending tasks, knock off all tasks from
device queue and reset card and controller as part of this, then
for all other software requests timeout, if it comes while executing
error work, we return BLK_EH_NOT_HANDLED.
This fixes BUG_ON in case of multiple requests timesout together.
2. Current code resets CQE, power cycle the card and requeue all the
requests in case of any error.
3. mmc_blk_cmdq_err work takes care freeing up all resource allocation
like clk and rpm hold, in case of reset_all.
4. Currently we were never clearing error CMDQ_STATE_ERR in case of any
error. This patch takes care of this bug.
Change-Id: I83d483c11fe2d7f2e462086cc3c0932057304c0d
Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>
[subhashj@codeaurora.org: fixed compilation error]
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
This patch does following-
This adds an API(mmc_cmdq_hw_reset), for RESET_ALL
of SDHCI, power cycle mmc card and
reintialize it, which enables cmdq as well(if supported).
This acquires claim_host before calling mmc_power_restore.
mmc_power_restore should be called with claim_host acquired,
since this function is required from non-claim-host context in
cmdq error handling.
Change-Id: I31c4449dead1d4ad4e10a4822cce2298ec5fb4b6
Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>
[subhashj@codeaurora.org: fixed merge conflicts, dropped some changes
related to mmc_do_hw_reset]
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Call mmc_/cmdq_post_req with tag number instead of
mrq. This is needed in error handling as part of multiple
request error handling.
Change-Id: I175432639d28378ec74669e31deb4d1667c49bb8
Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>
