summaryrefslogtreecommitdiff
path: root/include/linux
diff options
context:
space:
mode:
authorRitesh Harjani <riteshh@codeaurora.org>2015-08-05 11:27:00 +0530
committerSubhash Jadavani <subhashj@codeaurora.org>2016-05-31 15:27:22 -0700
commit35f2004cf997cd3969d00245debeecb2733da783 (patch)
tree909c56adad1ed1783d3d94106a7615dbf1166909 /include/linux
parent085c9196375e463476300d02691c249d1ca00362 (diff)
mmc: sdhci-msm: Set MMC_CAP_WAIT_WHILE_BUSY capability
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>
Diffstat (limited to 'include/linux')
0 files changed, 0 insertions, 0 deletions