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>
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>
IRQ of CSID is enabled when MSM_SD_NOTIFY_FREEZE is called.
It must be disabled in MSM_SD_UNNOTIFY_FREEZE and also
after few IRQs we disbale the debug IRQ.
This prevents excess logs.
Crs-Fixed: 1011965
Signed-off-by: Rajesh Bondugula <rajeshb@codeaurora.org>
Change-Id: I10bf7ed20e7d5d29c6e5fff0ed7a8474c96acea5
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>
Provide cmdq_host ops of enhanced strobe to notify
sdhci 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: I36ead91ca8c9aeed967f120f8bdc3d2180af7746
Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>
After halting CQE, if other commands are sent in legacy mode,
the timeout would be modified as per the requirements of the
command. Upon unhalting, this timeout would still persist for
CQE too, which in some cases may lead to timeout.
Hence, change the timeout to 0xf i.e. max during unhalt.
Change-Id: Ifb0a1f4b9508c5884d381401216ae6c1373bb7de
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
This change adds usage for runtime PM for devfreq
context.
In case clock scaling is done from devfreq context its
best to vote for runtime PM to avoid race between
scaling and PM.
Change-Id: I6fc7e2236b44b1f3a322da36552a7f9237c4dac6
Signed-off-by: Talel Shenhar <tatias@codeaurora.org>
This change removes the error value (-EAGAIN) that
is returned in case of invalid state for clock scaling.
Invalid state for clock scaling doesn't mean its an error,
it merely means that at the current time we won't scale.
Devfreq will invoke scaling in next interval.
Change-Id: Idbd785da83e6ed00ede2b1b09529f7c81714ccf8
Signed-off-by: Talel Shenhar <tatias@codeaurora.org>
This change disables clock scaling in PM notification
for "prepare for system suspend".
This is needed because devfreq creates a dependency
between it and mmc which causes an issue for system suspend.
In this change we break this dependency in earlier stage.
Change-Id: I86dad94c77607b4e8f8fa67035323716f5eb197d
Signed-off-by: Talel Shenhar <tatias@codeaurora.org>
If eMMC is not a primary bootdevice, there isn't any point of probing
eMMC device hence disable the probing in such case.
Change-Id: I92fa8c2ef373fd8a9140dbfb41356684aaa28e4e
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
