Update the error code to ENODEV if eMMC is not the boot device.
Change-Id: Ide0863a5aa64f9990d39095de6f6b13f752a6b3e
Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
Use the tag id of the error'd request and don't reset it to zero;
to handle the error'd request appropriately.
Change-Id: I0f5eac47197fa7b59208d0a61776d4ba186aa3dc
Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
The power on reset value of DDR_CONFIG register was fixed in
controller revision (major - 0x1 and minor > 0x49) to address
the default rclk delay value after characterization. The register
offset for this register was also changed starting from this
revision. Make necessary changes to account for this.
Change-Id: I4e4a87aebd24e5669b03a914c6e0f4b469f5ec7b
Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
This change adds use of devfreq suspend/resume API.
In the current version of the code, devfreq is fully brought
up/down on each runtime resume/suspend which causes
statistics loss and is time consuming.
This change addresses the above by adding support for
devfreq suspend/resume to be called on each system
suspend/resume, runtime suspend/resume, power restore.
Change-Id: Id209826fb9499084ae96c7d3a47e4032326f61e9
Signed-off-by: Talel Shenhar <tatias@codeaurora.org>
[subhashj@codeaurora.org: fixed merge conflicts]
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
In case of a crypto error during request submission clear the
host mrq structure in preparation for the next request and
dump the current register state for further debugging.
Change-Id: I2eeda8589ca4c83bbb4a1b372e9363224bbfb680
Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
For any cmd we have a DAT line timeouts which we set in TIMEOUT_CONTROL
register of sdhci. For commands with busy response (R1B), cmd is followed
by a busy period exercised by card, by pulling DAT0 line low
(in case of CMD5). Here host controller detects this busy period and
waits for either busy period to finish or timeout to happen based on
value set in SDHCI_TIMEOUT_CONTROL register.
Thus for R1B commands, host controller(sdhci) is capable of sending
two interrupts. 1st is the CMD response(0th bit - Command complete
of Normal Interrupt Status register ) and 2nd is when the busy period has
ended(1st bit - Transfer Complete bit of Normal Interrupt Status register).
If MMC_CAP_WAIT_WHILE_BUSY is not enabled by the host controller driver
then core layer explictely waits for fixed amount time specified by
s_a_timeout parameter which is generally very high when compared to
amount of time card keeps the DAT0 line low.
As sdhci-msm is capable of detecting this busy period, set
MMC_CAP_WAIT_WHILE_BUSY capability in the host controller driver
to avoid redundant wait period.
On 8952 this saves us ~110ms during mmc suspend.
Change-Id: Ibb3a70575a06a5ffd1ccc3adaa96dfb3c3e22e3a
Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>
We should keep either one of CDR_EN or CDR_EXT_EN enabled.
So correct this logic in toggle CDR function.
CRs-fixed: 759398
Change-Id: Ic137ae2a28e912ab131644ff9d81e41f4256dd05
Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>
Signed-off-by: Pavan Anamula <pavana@codeaurora.org>
During tuning the status command CMD13 needs to be sent to the
card to know the card's state upon any failure to tuning command.
Change-Id: Iaefc80305d101bd72ff22f792b1967379507a739
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Signed-off-by: Pavan Anamula <pavana@codeaurora.org>
Currently we enable CDR for every read command including
for tuning procedure which is not correct (as CDR if
enabled might correct the phase during tuning and we
wont be able to detect the correct phase during tuning).
So, disable CDR for read tuning commands.
CRs-fixed: 759398
Change-Id: I051b6e3b204dde22cdc973759c3e32d0a81c369a
Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>
Signed-off-by: Pavan Anamula <pavana@codeaurora.org>
During platform driver probe we call mmc_start_host in sdhci_add_host,
which could start the mmc_rescan work immediately and trigger a runtime
suspend. This creates a race condition where the clocks could be turned off
even before the probe has completed leading to unclocked register access.
CRs-Fixed: 770843
Change-Id: I77ae36f805e496d56ed96db3ccaa83f2c37c926c
Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
Some controllers may not have any LED control to indicate
its status. Use this quirk for such controllers to avoid
registering any LED device with LED class and also to
avoid exposing sysfs nodes which doesn't actually control
any LED.
Change-Id: I7e8f1b8d2d735685ede87df4bb7fb32ad0a10246
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Signed-off-by: Pavan Anamula <pavana@codeaurora.org>
[subhashj@codeaurora.org: fixed trivial merge conflicts]
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
The SDHCI reset for data is getting stuck on some of sdhci-msm
controllers. The SDHCI reset usually waits for any pending transfers
on the bus before proceeding with the controller reset. But in the
failure cases, the data transfer seems to be stuck on the bus and
thus preventing the controller from being reset. The workaround is
to force the controller to be reset under such scenarios. This seems
to be helping the controller to return back to good state at least
for the next commands following the failure.
This issue is found on SDCC5 controller of 8916/8939 and 8992 chipsets.
Hence, enable the quirk SDHCI_QUIRK2_USE_RESET_WORKAROUND only on those
controllers.
Change-Id: Id49009736beb410ccb2535d614786a7c48098f85
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Signed-off-by: Pavan Anamula <pavana@codeaurora.org>
The SDHCI reset for data is getting stuck on some of sdhci-msm
controllers. The SDHCI reset usually waits for any pending transfers
on the bus before proceeding with the controller reset. But in the
failure cases, the data transfer seems to be stuck on the bus and
thus preventing the controller from being reset. The workaround is
to force the controller to be reset under such scenarios.
This seems to be helping the controller to return back to good state
at least for the next commands following the failure.
Change-Id: I487bdf3bd4afb18e69afa778aa38c3574d69e2f7
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Signed-off-by: Pavan Anamula <pavana@codeaurora.org>
[subhashj@codeaurora.org: fixed trivial merge conflicts]
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
The SDHCI reset for data is getting stuck with the default
MID configuration which uses descriptor requests with MID=0
and data requests with MID=1. This enables interleaving
between MID and is causing reset to be stuck somewhere in the
path DDR<->NOC<->SDHC on few chipsets. Enable one MID mode
as a workaround to this problem which is observed on SDCC5
controller of 8916/8939 and 8992 chipsets.
Change-Id: I12343b35d45774668b7e823ccaa067813fcea4cf
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Signed-off-by: Pavan Anamula <pavana@codeaurora.org>
Runtime pm get/put calls need to be called in pairs. Fix the
unpaired call of runtime pm put after input validation.
Change-Id: Ice2ba1e4d17ffde48b2f4d59801bb962f2e9aae7
Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
In case card detect IRQ is triggered before mmc_add_host(), then
there could be a potential race between mmc_power_off() which gets
called frommmc_rescan() of card detect IRQ handler and
mmc_start_host() which gets called from mmc_add_host(). This may
turn off the clocks while mmc_start_host() is still running and thus
may result in an un-clocked register access.
Change-Id: I90ff99fb8e018b00600bf18197a2bcaf83ff1bc4
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Signed-off-by: Pavan Anamula <pavana@codeaurora.org>
[subhashj@codeaurora.org: fixed merge conflicts, removed
2nd pair of mmc_claim_host/mmc_remove_host calls from mmc_start_host]
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
SANITIZE is an operation performed by the storage device and its purpose
is to delete its unmap memory regions.
This change adds support for the SANITIZE capability.
Change-Id: I58b647fb576c694aaa16c1e827d0784d4a5b4456
Signed-off-by: Yaniv Gardi <ygardi@codeaurora.org>
Signed-off-by: Pavan Anamula <pavana@codeaurora.org>
[subhashj@codeaurora.org: fixed trivial merge conflicts]
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
pm qos is currently causing race conditions with runtime pm when
in cmdq mode. Disable this till it is addressed as part of the
pm qos redesign.
Change-Id: I32d04100bbf31995a249188eace164c8761e9141
Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
Change the rclk delay value to 0.9ns since testing shows
that the valid window may vary for different platforms and the
default value (1.25ns) might fall outside the valid window.
CRs-Fixed: 766702
Change-Id: I6e3522c2764047a773e028078b63e6e94e230d41
Signed-off-by: Dov Levenglick <dovl@codeaurora.org>
Signed-off-by: Pavan Anamula <pavana@codeaurora.org>
There is a rare scenario in HW, where the first clear pulse could
be lost when the actual reset and clear/read of status register
are happening at the same time. Fix this by retrying upto 10 times
to ensure the status register gets cleared. Otherwise, this will
lead to a spurious power IRQ which results in system instability.
Change-Id: I1c4f27e131992ef036ebe64fbb2c52613ba396cc
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Signed-off-by: Pavan Anamula <pavana@codeaurora.org>
If request has to be requeued due to cmdq being halted and if we change
the task status to interruptible before going to sleep then cmdq thread
may not wakeup again. Note that blk_requeue_request() doesn't trigger
->request_fn() again to wakeup the cmdq thread.
Fix this issue by kicking the queue once cmdq state machine is unhalted.
Change-Id: Icbfb3b6560285fa0a0ce7e83eee66b651d4594a0
Signed-off-by: Gilad Broner <gbroner@codeaurora.org>
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
This change makes sure we will do deferred scaling only
from data path and not for other requests such as mmc_switch.
Change-Id: I52142d7a0262ca8927c7c1c509235ead676aac97
Signed-off-by: Talel Shenhar <tatias@codeaurora.org>
[subhashj@codeaurora.org: fixed trivial merge conflicts]
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Clock scaling logic relies on active data request tracking variable to
start/stop counting the bus busy period and we are also crashing the
system if this tracking variable shows that new request tag is already
in use. Set/Clear logic of this tracking variable is done only if
clock scaling is enabled but consider following sequence of events:
1. Clock scaling is enabled
2. New request comes in which sets the appropriate tag in tracking
variable.
3. Clock scaling gets disabled (for some reason) before the request
completion.
4. Request gets completed but it doesn't clear the corresponding tag
in tracking variable.
5. Clock scaling gets re-enabled.
6. New request is issued with the same tag which was never cleared from
tracking variable hence we would hit the BUG_ON and system will crash.
Fix this issue by doing set/clear of tracking variable irrespective of
clock scaling state.
Change-Id: Idffd1247ec1275e782e1ad9eb91faa81bc3ba347
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Ensure the task descriptor list memory is flushed before ringing
the doorbell by adding a memory barrier. Also commit the doorbell
write immediately to help improve performance.
Change-Id: I321d5bed95b802d4bcc00836ce9cdede316b29f5
Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
If mmc/sd shutdown callback suspends the card when card's runtime PM status
is still set to "runtime active" then any request issued after mmc/sd
shutdown will not resume the card hence we will end up issuing the request
to host driver while card isn't in a state to handle it.
Right way to fix this issue is not to allow any requests to flow in after
the shutdown callback has executed. Until it is fixed in the right way, we
are disabling the shutdown handling as it anyways doesn't do real useful
things.
Change-Id: I44681f3c2fd0435bffa393abbbd1e8eacc5a07da
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
[subhashj@codeaurora.org: fixed trivial merge conflicts]
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
This is needed to scale up/down the ICE clock during runtime
as per the load on eMMC.
Change-Id: I60d06458767c817298783219caf767866e7bf12f
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Switch to using pr_err_ratelimited in order to avoid
flooding the logs in case of error function gets
called repeatedly.
CRs-Fixed: 837631
Change-Id: I08fffb7e77584ac7fe7ba7152677cc12293e1655
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
Signed-off-by: Pavan Anamula <pavana@codeaurora.org>
After issuing a request the usage_count is decremented. After idle time
controller irq is disabled by platform device runtime pm and request
complete irq is not handled.
This change moves decrement of usage_count from the end of issuing request
to the end of request completion.
Change-Id: I1322e0d1ab4ffbf50956fec2921c778e0dcddf36
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
Block layer queue on suspend flow gives up if there are active requests,
while shutdown flow stops issuing thread and waits for completion of
outstanding requests and never give up.
This change propagates additional parameter to differentiate between
suspend and shutdown flows
Change-Id: I35a036c1a5585e3088301c07ade7d09ebd2cfc1b
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
[subhashj@codeaurora.org: fixed merge conflicts]
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Some devices do not honor the max switch timeout exposed via
ext_csd, they take longer than that to complete the switch.
Hence add a retry mechanism to wait longer for the card to
get out of programming state before timing out.
Change-Id: Ica46e30df24b4f95f457271087e1e03823ed2959
Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
[subhashj@codeaurora.org: fixed merge conflicts]
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
In 3.18 kernel mmc_gpiod_request_cd_irq() is not called as part of
call to mmc_gpio_request_cd(). During probe this is taken care of
by calling mmc_gpiod_request_cd_irq() from mmc_start_host(), but if
mmc_gpio_request_cd() followed by a mmc_gpio_free_cd() is invoked
after mmc_start_host() (such as in system suspend/resume path) then
mmc_gpiod_request_cd_irq() needs to be called explicitly.
Instead of free/request the card detect irq, just disable/enable
the irq in system suspend/resume path.
CRs-fixed: 876453
Change-Id: I976cd5061c2a7d8321e48ee23a44acfd552a37fc
Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
Currently getting status/ext_csd using debugfs or IOCTL
calls in cmdq mode is not working.
Fix it by halting the cmdq engine and making sure that
card queue is empty before issuing these cmds.
Change-Id: Idb89def9ff5c2fee6866759b9a8c652049552933
Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>
[subhashj@codeaurora.org: fixed merge conflicts]
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
CMDQ spec defines periodic SEND_STATUS mechanism to poll
on READY tasks in the device. When DAT lines are in IDLE
the counter counts from its reset value to '0' and then
triggers SEND_STATUS command. When CMD13 is completed and
also the syncing of the device status to HCLK domain is done
there is a 1 cycle pulse to reload the counter with timer
reset value so that the counting can start over.
In rare cases, when the 'done' pulse for reloading the
counter happens in parallel to a BUSY state of direct
command - the IDLE counter is not reloaded and can't
trigger another CMD13. If this scenario happens when
there are pending tasks which are not 'READY' yet - it
can lead to a deadlock, since there is no other mechainsm to
send CMD13, and CQE will never get READY on the pending tasks.
Hence, trigger a send status command after DCMD is completed
as a work-around to the above issue.
Change-Id: I4e8530e72c8bf581ffaeed7d35d8b8c61d282ffa
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
The cmdqd thread was marked as uninterruptible. This did not
allow the cmdqd thread to sleep when there is no traffic.
Added interruptible attributes to the thread.
Change-Id: I658eecabfff074044b23c7c270c9101a34d37a45
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
Right now only certain amount of delay (146 MCLK cycles as per spec)
is given for card to return back to transfer state upon any CMD error
that host controller may receive. This delay seems to be insufficient
for certain eMMC cards like Hynix. This patch tries to send CMD13 and
also retry it with the same delay to make sure the card is back to
transfer state before sending next command. Otherwise we may see auto
cmd or illegal command failures to the read command sent right after
tuning, especially if the last tuning phase has failed.
Change-Id: I3ec2da150dc5ee656b8156040bf539812b0e4d2b
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Signed-off-by: Pavan Anamula <pavana@codeaurora.org>
[subhashj@codeaurora.org: fixed trivial conflicts]
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
System suspend executed on kernel PM core context. When there are active
requests system suspend is rejected. Semaphore used to resolve race
between mmc_cmdq_thread() and mmc_queue_suspend().
Change-Id: I88f668d7a6dd6403407ac8208265e4439b35173c
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
Changing the test of whether auto_bkops is configured
allows for a case where the host tried to configure
auto_bkops yet the CMD6 failed in configuring the
device. This allows a case where manual bkops is configured
on a eMMC 5.1 device
Change-Id: Ia6c411f516bf27b8a5865109dcf4b290eb3d8e46
Signed-off-by: Dov Levenglick <dovl@codeaurora.org>
[subhashj@codeaurora.org: fixed trivial merge conflicts &
fixed compilation error]
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Certain Hynix eMMC 5.0 cards might reach a fast EOL if
the card's power is disabled between CMD5 and CMD0
(power off during reset).
This patch sets the MMC_PM_KEEP_POWER flag to indicate
that the card's power should be retained for suspend/resume
sequences.
Change-Id: I4bcc0f4bfd608745626816ca261369b432602c45
Signed-off-by: Dov Levenglick <dovl@codeaurora.org>
There are eMMC cards that should not be powered off
during suspend/resume cycles.
This patch adds support for such cards and avoids powering
the card off during suspend or powering it back on
during resume when MMC_PM_KEEP_POWER is set.
Change-Id: Iec1a0aac80ee41dff56f192e7253c2bd00c15694
Signed-off-by: Dov Levenglick <dovl@codeaurora.org>
Add MMC_PM_KEEP_POWER specifically when connected to
SDIO cards, rather than in general for the host.
Change-Id: Idb666680f99277ae509c642595821448c21b6c90
Signed-off-by: Dov Levenglick <dovl@codeaurora.org>
Add call from sdio to host_ops to sdhci_ops
in order to indicate when a sdio card is detected.
This will be used by hosts that require special
handling for card detection.
Change-Id: I65ec6ee464d658cd938d9254a0a748e6137f9223
Signed-off-by: Dov Levenglick <dovl@codeaurora.org>
[subhashj@codeaurora.org: fixed trivial merge conflicts]
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
This change fixes an issue that can happen for clock scaling
sequence during command-queue.
This is the sequence for scaling the clocks in case of
command queuing:
1) Halt queue
2) Check if state invalid
3) Scale clocks
4) Un-halt scale
In case step 2 fails (e.g. device state is different
than R1_STATE_TRAN), we should avoid scaling the clocks and
un-halt the queue. The issue was that step 4 was not
happening in case of invalid state, this change fixes it.
Change-Id: I308b0d6406631febe364d14de7551eb7f628cb40
Signed-off-by: Talel Shenhar <tatias@codeaurora.org>
The bkops exception handling will ignore cases when
auto bkops is enabled. As such, limiting the enablement
of the exception in cmdq mode to when manual bkops is
enabled yet auto bkops is not.
Change-Id: Icc158cf2c7a2dda6e8b9f1eee8a5924e14330d1f
Signed-off-by: Dov Levenglick <dovl@codeaurora.org>
The change in pull configs might not take into effect immediately
and any value read before it is stabilized will mark incorrect
card status. This causes SD card detection to fail when inserted
for the first time. Fix this by adding enough delay after
configuring the GPIO and before reading its value.
Change-Id: I3a8455ce404988ab5eb3ed04c0f90ab6edf76d86
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Signed-off-by: Pavan Anamula <pavana@codeaurora.org>
The shutdown handler waits for in-flight requests only.
It stops the block queue, but doesn't issue the already
queued requests to the LLD. Furthermore, a request which
is in the process of being queued will timeout eventually
because CQE would be halted by shutdown handler.
mmc_cmdq_thread(mct) -> pulls request (r1)
shutdown invoked
stops block queue
halts cqe
(mct) -> issues r1 to LLD
- pulls already issued requests
- CQE halted -> requeues request
- issued request (r1) times out
Hence, in shutdown handler
- stop the block layer queue
- set a state indicating shutdown
- wake up mmc_cmdqd
- mmc_cmdqd:
- pull requests and issue to LLD
- complete the issuing of already queued requests
- wake up shutdown handler
- wait for completion from mmc_cmdqd
- wait for all issued request to complete
- proceed with shutdown
Change-Id: I30a9664d8ba2f4b4f580c2cf71c5d01b735c9491
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
When sending CMD during data in HS400 Enhanced Strobe mode,
the command that is being sent is also sampled internally on
CMDIN line by the RCLK that is toggling due to the data traffic.
To mask this <false> CMDIN a new mask is introduced throughout
the CMD transmission time. This mask is controlled by
HC_VENDOR_SPECIFIC_FUNC3.CMDEN_HS400_INPUT_MASK_CNT register.
The default reset value of this register is 2.
Before running CMDQ transfers in HS400 Enhanced Strobe mode,
SW should write 3 to
HC_VENDOR_SPECIFIC_FUNC3.CMDEN_HS400_INPUT_MASK_CNT register.
Change-Id: If0467855e23cb93e57a4581b375885136902835d
Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>
Provide sdhci host ops of enhanced strobe to notify
sdhci-msm on enabling/disabling cmdq. This is needed
because of following:
Before running CMDQ transfers in HS400 Enhanced Strobe mode,
SW should write 3 to
HC_VENDOR_SPECIFIC_FUNC3.CMDEN_HS400_INPUT_MASK_CNT register.
Default reset value of this register is 2.
Change-Id: I987605cd21f137dea49ddf3e8db3f1f41b5b501f
Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>
[subhashj@codeaurora.org: fixed trivial merge conflicts]
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
