Should check if mmc_card supports strobe before calling
enhanced strobe host ops. This also adds a macro for use
by LLD to know if card supports strobe
Change-Id: Id79098ff66bd36be2496b86bf71556204aca7fe3
Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>
[subhashj@codeaurora.org: fixed trivial merge conflicts]
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
When encryption/decryption is enabled in CQ mode, the
legacy commands that are sent in HALT state will use
different slot other than slot 0 for crypto configuration
information. The slot that is selected depends on the last
slot that was used when it is in CQ mode. This is causing
the data of legacy commands to be encrypted/decrypted based
on the wrong slot usage for crypto config details. Hence,
clear the crypto configuration of the slot used in CQ mode
whenever it gets completed.
Change-Id: If573de5025054a10de1dde544aa79022016f65fd
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
The mmc_queue_req will be present only if the request is issued
to the LLD. The request could be fetched from block layer queue
but could be waiting to be issued (for e.g. clock scaling is
waiting for an empty cmdq queue). Evaluate such cases and reset
the timer to give LLD more time.
Change-Id: Ic5818f5c2b8356bda9b1612d78b65e07dad011d7
Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
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>
Zcache could be ineffective if the compressed memory pool is full with
compressed inactive file pages and most of them will be never used again.
So we pick up pages from active file list only, those pages would probably
be accessed again. Compress them in memory can reduce the latency
significantly compared with rereading from disk.
When a file page is shrunk from active file list to inactive file list,
PageActive flag is also cleared.
So adding an extra WasActive page flag for zcache to know whether the
file page was shrunk from the active list.
Change-Id: Ida1f4db17075d1f6f825ef7ce2b3bae4eb799e3f
Signed-off-by: Bob Liu <bob.liu@oracle.com>
Patch-mainline: linux-mm @ 2013-08-06 11:36:17
[vinmenon@codeaurora.org: trivial merge conflict fixes, checkpatch fixes,
fix the definitions of was_active page flag so that it does not create
compile time errors with CONFIG_CLEANCACHE disabled. Also remove the
unnecessary use of PG_was_active in PAGE_FLAGS_CHECK_AT_PREP. Since
was_active is a requirement for zcache, make the definitions dependent on
CONFIG_ZCACHE rather than CONFIG_CLEANCACHE.]
Signed-off-by: Vinayak Menon <vinmenon@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>
