Enable the legacy interrupts immediately after halt interrupt is
handled, from cmdq_irq() itself.
When cmdq halt is initiated, as per existing logic driver waits either
for halt interrupt to fire or for certain period of time. In case if
cmdq is halted but halt interrupt got delayed than wait-timeout period,
driver disables cmdq interrupts since cmdq is in halt state.
The delayed halt interrupt gets fired only when cmdq is unhalted next
time and cmdq interrupts are enabled. And this delayed interrupt is
treated as an unexpected interrupt.
By enabling legacy interrupts (i.e., disabling cmdq interrupts) from
cmdq_irq(), we can ensure that we don't disable cmdq interrupts until
halt interrupt get fired. So we can avoid above mentioned scenario.
Change-Id: Ic052d41fac789b6390a5d80dfaee91767bdb783f
Signed-off-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org>
When system is heavily loaded, in some cases interrupt servicing
is getting effected and cmdq halt interrupt handler is getting invoked
after 1 sec delay. Since wait time of HAC interrupt in cmdq driver
is 1 sec, the delayed interrupt is being treated as unexpected
interrupt.
For fixing this case, increasing the timeout to 10 seconds.
Change-Id: I55879095aa2b81a10f40963aee02b2068a3305b4
Signed-off-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org>
For SDHC version 5.0 onwards, ICE3.0 specific
registers are added in CQ register space, due to
which few CQ registers(like CQ_VENDOR_GFG,
CQ_CMD_DBG_RAM) are shifted. This change is to
update CQ register offset for sdm660.
Change-Id: Ie85b8f6c68511dccd2b545bd9cc17c747f3da8e7
Signed-off-by: Sayali Lokhande <sayalil@codeaurora.org>
According to specs, some commands require a delay after
issuing the command. idata->ic struct is received from
user in mmc_blk_ioctl_cmd(). So idata->ic.postsleep_min_us,
idata->ic.postsleep_max_us are user controlled. If the min
and max values are set such as max < min, then operation in
the function do_usleep_range will overflow. For avoiding this,
put a condition for checking max < min. If the condition is
true, then print the error message with respective values and
return error.
Change-Id: I76828b58aa46fc4e195da4ae0babb02a7abf6bbe
Signed-off-by: Siba Prasad <sibap@codeaurora.org>
commit 161e6d44a5e2d3f85365cb717d60e363171b39e6 upstream.
One of our kernelCI boxes hanged at boot because a faulty eSDHC device
was triggering spurious CARD_INT interrupts for SD cards, causing CMD52
reads, which are not allowed for SD devices. This adds a sanity check
to the interruption path, preventing that illegal command from getting
sent if the CARD_INT interruption should be disabled.
This quirk allows that particular machine to resume boot despite the
faulty hardware, instead of getting hung dealing with thousands of
mishandled interrupts.
Suggested-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.co.uk>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Due to deferred resume enabled ->
|
in system suspend
|
dpm_prepare
|
mmc_pm_notify with PREPARE_SUSPEND
This will return from here and will not wait
for mmc_rescan to complete.
Because of above system has deadlocked in which =>
mmc_rescan after acquiring device's mutex_lock, has
scheduled a work on WQ_FREEZABLE(bdi_wq) which will not run
since system freeze state has already completed.
This will only complete once tasks are unfreezed
which means only after system resume is completed.
And system suspend, is unpreparing the devices from dpm_prepared_list.
During which this process is trying to acquire card->device's mutex lock
which is held by above process. Thus a deadlock.
Change-Id: I926bb3783e62892ce842e5d4da44a3c24c8f244d
Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>
Currently there is one rare case where suspend thread trying
to suspend sdhci-msm waits infinitely for pwr_irq interrupt
from hardware which never gets raised and thus watchdog barks
happens.
Change this waiting to wait_for_completion_timeout.
Change-Id: Ic4e9bca91b5496409b4afe2be2892c83aa390e95
Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>
SDHC v5.0 onwards, SDHC includes the inline interface for
cryptographic operations which is ICE HCI.
This patch includes the driver changes for supporting crypto
operations with ICE HCI in noncq mode.
Change-Id: I3253b796212f63853cb3f6cf130f0a8542595428
Signed-off-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org>
Add new sdhci host_op for updating ice configuration while sending
request through cmdq. Adding provision for supporting the ice
context configuration for ICE HCI.
Change-Id: I0e7299cfb1064c117aa94fb2416cc5cc4f1ec5f6
Signed-off-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org>
On SDHC v5.0 onwards, SDHC includes the inline interface
for cryptographic operations which is ICE HCI.
This patch includes the driver changes for supporting crypto
operations with ICE HCI in cmdq mode.
Change-Id: I618a0a4b7356f2f19c31d67fca1664daa51b09f9
Signed-off-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org>
Factor out the logic of getting ice config parameters from
sdhci_msm_ice_cfg().
With ICE2.0, same sdhci_msm_ice_cfg function is being called from cmdq
and noncq. But with ICE3.0 support, cmdq needs a separate host op.
Since this logic of getting ice config is common for noncq and cmdq,
by having it in separate function, same can be reused
in cmdq host op as-well.
Change-Id: If2cf26667acd54cb7ee7bd6283d8f24fcbf60791
Signed-off-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org>
Factor out the logic of updating the SDHC ICE config registers
from sdhci_msm_ice_cfg().
For ICE3.0, different set of SDHC ICE registers are need to be updated.
So having this logic in separate functions, we can have logical
separation for ICE2.0 and ICE3.0.
Change-Id: Ib3d3f9701875000985dc9382bdcdf5fb0e872a43
Signed-off-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org>
SDHC v5.0 onwards the ICE reset register offset got updated.
Update the register offset based on the SDHC version.
Change-Id: I9c1250460cddf72837446b54fe03e3c52f11b234
Signed-off-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org>
Check if the SDHC has ICE HCI support. If support is present,
enable the cryptoghrapic support inside SDHC.
Also ensure that it is re-enabled after SDHC is reset.
By default ICE HCI is disabled.
Change-Id: I43a65279088d70b415c396bc3e51e0e510bb7f9c
Signed-off-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org>
Generally, during card suspend we call mmc_power_off
and disable controller clocks.
Now consider below sequence of events :
suspend -> resume -> suspend.
1) During first platform suspend, mmc_power_off will
be called and clocks would be disabled.
2) As a part of platform resume, we enable controller
clocks and defer card resume when
MMC_BUSRESUME_NEEDS_RESUME flag is set.
3) During next suspend we check if card is already
suspended (i.e MMC_BUSRESUME_NEEDS_RESUME is set)
and return without doing actual suspend (where we
call mmc_power_off and disable controller clocks).
So in this scenario, controller clocks will remain ON
even though card state is SUSPENDED.
Fix this by disabling controller clocks during suspend
if controller clock was ON.
CRs-Fixed: 1088893
Change-Id: Id54a15d7f6a7131dab609eec1db158c64ada83ce
Signed-off-by: Sayali Lokhande <sayalil@codeaurora.org>
commit 01167c7b9cbf099c69fe411a228e4e9c7104e123 upstream.
According to the code the intention is to append 8 SCK cycles
instead of 4 at end of a MMC_STOP_TRANSMISSION command. But this
will never happened because it's an AC command not an ADTC command.
So fix this by moving the statement into the right function.
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Fixes: e4243f13d1 (mmc: mxs-mmc: add mmc host driver for i.MX23/28)
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This provides module/cmdline parameter for disabling cmdq.
This may be required sometimes for testing cmdq v/s non-cmdq
mode for performance or other stability testing.
Pass cmdline parameter as (sdhci-msm.nocmdq=1) for disabling
cmdq via cmdline.
Change-Id: Ic0993a58d79f9c9b92daa7a581a5bce9ea24ed03
Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>
The config vop of the ice driver has been updated to config_start.
Updated the sdhci-ice driver to reflect this change.
Change-Id: I7c44cc5011c6a7c88b9acf9cb9d8e61ef3f8e33a
Signed-off-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org>
Enabling deferred resume feature on SDM660. With this feature
enabled, MMC devices won't be resumed as part of the system
resume. It will be resumed only when there's a request to be
processed.
Change-Id: I901a888269b8bc0de006c8174546fd5f5c30baa8
Signed-off-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org>
During error scenario, if interrupt status of CQ controller is cleared
before halting the controller, the CQ controller can send commands to
card in the time delay between clearing of interrupt and halting. The
response of card to these commands can overwrite the error information
stored in Response Arg register. So, if an error is detected, the CQ
must be halted first and then the interrupt must be cleared.
Change-Id: Ief7039226b01b50fc71cf17a4eb625afd8c9bd06
Signed-off-by: Vijay Viswanath <vviswana@codeaurora.org>
commit 16652a936e96f5dae53c3fbd38a570497baadaa8 upstream.
We never set "ret" to RESULT_OK.
Fixes: 9f9c4180f8 ("mmc: mmc_test: add test for non-blocking transfers")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Do not send CMD13 after sending switch command for HS, HS_DDR,
HS200 and HS400 modes. It seems that below problem can occur -
1. After sending switch CMD6, card will switch to mentioned bus speed
mode.
2. At this moment the controller will be in different bus speed mode,
unless the timing of the controller is switched to match with that of
card.
During this time, if CMD13 follows CMD6 to switch the bus speed
mode in card. Then it may cause timeouts or other errors because
of mismatch in timing of controller and card.
Thus send CMD13 to see the status once both controller and card are
switched to same timings.
Change-Id: If796c8cfce2cbdc1bce460460e3276886ae1be0c
Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>
Signed-off-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org>
Signed-off-by: Sayali Lokhande <sayalil@codeaurora.org>
Add ring buffer to enable tracing of significant events
of eMMC in both CQ and Legacy mode for debug purpose.
CONFIG_MMC_RING_BUFFER should be enabled to use ring
buffer logging.
Change-Id: Iceb404d77fca19e133c319bc66ec15b2d77c7c54
Signed-off-by: Sayali Lokhande <sayalil@codeaurora.org>
commit 61e53bd0047d58caee0c7170613045bf96de4458 upstream.
Clearing the tuning bits should reset the tuning circuit. However there is
more to do. Reset the command and data lines for good measure, and then
for eMMC ensure the card is not still trying to process a tuning command by
sending a stop command.
Note the JEDEC eMMC specification says the stop command (CMD12) can be used
to stop a tuning command (CMD21) whereas the SD specification is silent on
the subject with respect to the SD tuning command (CMD19). Considering that
CMD12 is not a valid SDIO command, the stop command is sent only when the
tuning command is CMD21 i.e. for eMMC. That addresses cases seen so far
which have been on eMMC.
Note that this replaces the commit fe5fb2e3b58f ("mmc: sdhci: Reset cmd and
data circuits after tuning failure") which is being reverted for v4.9+.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Tested-by: Dan O'Donovan <dan@emutex.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
It is preferred to use blk_cleanup_queue() instead of
blk_stop_queue() during reboot/shutdown due to these reasons -
1. blk_cleanup_queue() marks the queue as dying/dead which prevents
the new requests from getting inserted into the queue after MMC
driver shutdown.
If we just use blk_stop_queue(), the requests are still allowed into the
request_queue but are not dispatched to the low level MMC driver as the
queue is marked as stopped. This may result into deadlock/hang issue during
shutdown, if FS (as part of emergency remount) is waiting for the queued
request to be completed without relinquishing the CPU. If some CPU bound
workqueues related to shutdown are pending on that CPU, then shutdown
may hang.
2. blk_cleanup_queue() also drains the queue completely by processing
all the pending requests from the elevator queue even though those are
not yet dispatched to request_queue and also waits for the completion
of all those requests.
Also, do not override the queue_lock in request_queue structure with
md->lock as this will cause below problem when using blk_cleanup_queue() in
shutdown. This happens because blk_cleanup_queue() changes queue_lock
from driver md->lock to it's original request_queue lock.
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
Change-Id: Iaa26944ccc6c279390215869f5003156400840ed
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
