No need to check for valid state when we want to
scale down the clocks. As this state validity
check is to only address that clk scaling
doesnt scale up (which will send tuning
cmds) during definite cmds sequences (like
erase operation).
CRs-Fixed: 800478
Change-Id: Ia7a578434d7db8983493788ab2d7f9383d703169
Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>
The unclocked access could happen in the following scenario -
1. mmcqd thread is waiting for previously submitted io to be done
2. before this io is done, it is woken up due to is_urgent event
3. mmcqd thread is running and is processing the is_urgent event
4. Just about the same time the previously submitted io is done and
it sets is_done_rcv flag, tries to wake up mmcqd thread and release
host clock so as to gate the clocks.
If step 3 and 4 happen at the same time, then clocks will be gated off
before is_urgent is completely handled. Hence, make sure to hold the
clock before invoking get_xfer_remain and stop_request host->op.
Change-Id: If03177bf5e28cc217cc8e86b10d81d4adbab78b9
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Mmc thread is waiting for one of following events occurs:
- current running request completion (is_done_rcv)
- new request notification arrived (is_new_req)
- urgent request notification arrived (is_urgent)
or the thread received a signal. In this case none of described events
happened.
This change process the case, when mmc thread was unblocked from wait by
signal, for example system shutdown flow.
Change-Id: I0b4f0cefedc839640c162ad3cdb011d13daaee0c
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
There could be a race between suspend and mmc_rescan as follows:
At resume:
-> mmc_pm_notify
-> mmc_rescan is scheduled
Suspend is triggered:
-> mmc_pm_notify
-> wait for mmc_rescan/cancel it
-> rescan acquires wakelock if card is detected
so as to give user-space a chance to respond
-> PM framework cancels suspend since wakelock is active
Hence, release the wake-lock if its active in suspend prepare
and check for rescan_disable before acquiring wake-lock.
This prefers suspend over notifying the user-space of the status
of the card, which is fine since with suspend user-space is frozen
too.
CRs-fixed: 655281
Change-Id: I83783589f9b541d3af73931e9a7b0b144a25538e
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
If get_cd is defined and card is not present mmc_rescan
returns without invoking mmc_power_off. This would prevent
low-power modes.
Hence, invoke mmc_power_off if card is not present before
exiting mmc_rescan.
CRs-fixed: 655754
Change-Id: Id148fdf48e7f112da1251f8b60ac5d4c89a89e9f
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
Function _mmc_detect_card_removed will be called to know whether
the card is still present when host->bus_ops->detect is called.
In current code, the return value of this function generally only
depend on the result of sending cmd13 to card, which may not safe
for card with detection support like slot gpio detection.
Because the communication status between host and card may out of
sync with the detect status if remove the card slowly or hands shake
during the process. The direct reason is the async between card
detect switch and card/slot pad contaction in hardware, which is
defined by spec.
The spec define card insert/remove sequence as below (both standard size
SD card and MicroSD card have the same sequence):
"Part 1 Standard Size SD Card Mechanical Addendum Ver4.00 Final,
Appendix C: Card Detection Switch" (Take normally open type as example)
a)SD card insertion sequence:
The card detection switch should be turned on after all SD card
contact pads are connected to the host connector contact pads.
b)SD removal sequence:
The card detection switch should be turned off when the SD card
is just going to be removed and before any SD card contact pad is
disconnected from the host connector contact pad.
Below is the sequence when this issue occur (Take slot gpio detection
as example and remove the card slowly during the process):
1. gpio level changed and card detect interrupt triggered.
2. mmc_rescan was launched.
3. the card pads were still contacted with the slot pads because of slow
removal. So _mmc_detect_card_removed and mmc_rescan think card was
still present (cmd13 succeed).
4. card pads were discontacted from the card slot pads.
So the card was actually removed finally but the card removal event
has been missed by system.
The interval length between step 1 and step 4 depends on the
card removal speed. If it's longer than the detect work schedule
delay which is 200ms, this issue will likely happen.
This patch add the card detect status check in function
_mmc_detect_card_removed if cmd13 check succeed and host->ops->get_cd
provided. If get_cd detect no card present then schedule another detect
work 200ms later.
CRs-fixed: 655754
Change-Id: I167309242c9937b023d14797177deb0e6be8838d
Signed-off-by: Kevin Liu <kliu5@marvell.com>
Git-commit: 1450734ec61cda7bbb77afc8cb412b9d64c62d9a
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc.git
Tested-by: Johan Rudholm <johan.rudholm@stericsson.com>
Reviewed-by: Philip Rakity <prakity@nvidia.com>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
eMMC and SD card specifications restrict the usage of a class of
commands while commands in other class are in progress. For example,
during erase operations the SD/eMMC spec. allows only CMD35, CMD36,
CMD38. If clock scaling is enabled and decide to scale up the clocks
it may be possible that CMD19/21 tuning commands are sent in between
erase commands, which is illegal as per specification.
Fix such illegal transactions to the card and also make clock scaling
statistics accountable only for read/write commands instead of time
consuming commands, like CMD38 erase, where transactions are independent
of bus frequency.
Change-Id: Iffba175787837e7f95bde8970f19d0f0f9d7d67d
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
This patch enables the deferred resume support which would
prevent initialization of the card each time the system resumes.
With this change, the resume process would only be initiated if
a request is received.
Following scenario can occur:
1. device runtime suspended, system suspend is triggered
When resumed, the device would not be resumed until a
request is received.
2. device is runtime active, system suspend is triggered
When resumed, the device would be marked as BUS_NEEDS_RESUME
and actual resume would happen, when a request is received.
At this point, the device may also enter runtime-suspend or
system suspend may also occur. In both the cases, since the
device has not been resumed, it won't be suspended again.
However, the platform device would be runtime suspended
and resumed as before.
It can so happen that the card is removed even before a
request is received. In this case the device would be
resumed and card would be removed from core layer and
upper layers would be notified.
In case of SDIO cards, this change would not have any effect
since manual resume would be enabled for devices supporting
a block read/write commands.
CRs-Fixed: 561382
Change-Id: Id39befea109ee24864dfde0898395b972d0a1b3a
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
This change prevents enabling cache during card init for Hynix cards.
This change is workaround the problem of Hynix cards behavior for
adb reboot flow, when as a result of power cycle with cache enabled,
ext4 journal get aborted, because of meta data corruption.
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
Conflicts:
drivers/mmc/card/block.c
include/linux/mmc/card.h
Change-Id: I721689da65e803965f1c7dd148754c4f19a64857
Signed-off-by: Maya Erez <merez@codeaurora.org>
As a result of following fix: "mmc: core: do not reinsert prepeared
FUA and FLUSH requests in stop flow" REQ_FUA and REQ_FLUSH requests
are not reinserted back into i/o scheduler, but instead started request
execution.
This change will prevent cleaning current request pointer for such
requests.
Change-Id: I25f8706954fb538be62182c87d5fb20354696b7a
CRs-fixed: 600127
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
In case if a removable card is hot-plugged when the card and host
are runtime suspended then the mmc_rescan() tries to detect the card
status and removes the bus_ops. During card removal the Linux device
model calls pm_runtime_remove() of the corresponding "card" device,
which not only marks the device as suspended but also notifies the
parent so that it can be suspended if there are no children that are
holding resume. In case if the runtime suspend work of host is scheduled
before bus_ops are marked NULL in mmc_rescan(), the runtime suspend
of host fails with -ENOMEDIUM error. This error makes runtime PM framework
to permanently mark the host device in error and further runtime PM
operations are disallowed even when the card is re-inserted.
CRs-Fixed: 593475
Change-Id: Ie5e09f05ef26098c561b0c64b3954962d9d4c039
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
When mmc context has unblocked from waiting current request because of
urgent request notification coming from block layer, there is prepeared
request. In the case, when the request is REQ_FUA or REQ_FLUSH, the
flow should not reinsert it back to i/o scheduler (since according to
block layer logic flush requests with data should never enter elevator).
Instead this request starts immediately.
Change-Id: Ia78b56c6135dd1a8d75a98fd5b771a5035e5c360
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
Add a quirk to increase the data-timeout value for Hynix eMMC
cards only. This value is fixed to a maximum of 4 seconds.
Change-Id: I4bca6cbc877b323b29a3f7f5923d0708c48adf2c
CRs-fixed: 587284
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
According to eMMC specification, there is no upper bound defined on
a flush request and the duration of flush operation is left to card
vendor's implementation. This means that it may take a very long
time to complete.
When eMMC cache is disabled, the card has to flush all the data in its
cache. So this means that for certain cards, the driver is not waiting
long enough for the flush to complete during cache disable operation,
leading to data on the card being corrupted.
This change increases the timeout for cache disable operation, thus
preventing data corruption.
CRs-Fixed: 562350
Change-Id: If68328ab56b50c7596800f07ef92c0ab16a55ec0
Signed-off-by: Maya Erez <merez@codeaurora.org>
Signed-off-by: David Ng <dave@codeaurora.org>
Signed-off-by: Krishna Konda <kkonda@codeaurora.org>
This patch adds clock scaling support to HS400 cards.
Scaling down to 52MHz from HS400 involves:
- switching the bus-speed mode to HS at 52MHz
Scaling up to HS400 would require all of the initialization
process upto HS400 mode selection.
Change-Id: I8196d6666bcc0ef327659253df53a17792fa51f7
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Krishna Konda <kkonda@codeaurora.org>
When mmc_stop_request() has no request to stop, because underlying
host driver reported this, the flow should wait for the mmc done()
callback marking that urgent still pending.
Change-Id: Iacc95591ee76a965916af05a31a67dd8997c233e
CRs-Fixed: 538117
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
On some eMMC cards cache flush is taking longer than 30 sec timeout
after HPI issued and -EIO reported to the upper layers. This may result
into journaling issues as flush calls are issued by the file system
joulrnaling code.
This change increases flash cache timeout to 90 sec, in case of timeout
occurs, after HPI issued, flash request re-queued to the block layer queue
to execute it later and keep journaling logic valid.
Conflicts:
drivers/mmc/card/block.c
Change-Id: I1e968c07056062fd9c8e14e5bc3e62b3b4b99c64
Signed-off-by: Panwar Vivek <vpanwa@codeaurora.org>
Conflicts:
drivers/mmc/card/block.c
Signed-off-by: Maya Erez <merez@codeaurora.org>
Up until now the FLUSH timeout error was not printed and there
was no way to know if the FLUSH completed successfully or not.
Printing the FLUSH failure will help to identify if FS corruption
happened due to this timeout.
Change-Id: Ibbb51d030d7130d63974a1b4319ad4a24621c595
Signed-off-by: Maya Erez <merez@codeaurora.org>
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
Certain Hynix eMMC 4.41 cards might get broken when HPI feature is used
and hence this patch disables the HPI feature for such buggy cards.
As some of the other features like BKOPs/Cache/Sanitize are dependent on
HPI feature, those features would also get disabled if HPI is disabled.
Change-Id: I6a638ce089cbd977122e47aecb721bc3f0adf7b0
Signed-off-by: Pratibhasagar V <pratibha@codeaurora.org>
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
At the moment if the block layer issues an URGENT request notification
before receiving a complete on the URGENT request currently handled by
the device driver - the system crashes with a BUG_ON().
This change enables multiple block layer urgent request notification to
be handled by MMC layer by removing single notification enforcement.
CRs-fixed: 517724
Change-Id: Idfa410d0c2286146f8d58a38b5abd6886036317c
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
According to the eMMC 4.5 spec "Flushing a large amount of cached data may
take very unpredictably long time". Therefore the timeout for FLUSH should
be increased to prevent timeouts.
In case the timeout occurs HPI issued.
CRs-Fixed: 500874
Change-Id: Ib00d087d3fe2fa72f5eac096976d3f24b5e4966a
Signed-off-by: Maya Erez <merez@codeaurora.org>
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
There could be a race condition in the stop transmission request.
1. Urgent read request comes in.
2. Stop the ongoing write request by calling stop_request MMC host op.
3. Send the stop command (CMD12) to move the card from the receive state
to programming state.
4. Send the status command (CMD13) to know if the card is in programming
state or not. If yes, then go to step.5 or else go to step.6.
5. Send the HPI command to bring the card out of programming state.
6. Now send the urgent read request.
In above sequence in step.4, we check if the card is in programming or
not and if it is then we go ahead and send the HPI in step.5 but what if
after step.4 is completed and before the step.5, card moves out of the
programming state so in that case HPI command would timeout as we are
sending it in the wrong state. In that case no command response (by eMMC
protocol) causes mmc_send_hpi_cmd to fail (with -ETIMEOUT error). In
case the card indeed in TRAN state, no error is reported.
Change-Id: Ia6f81f6cc4ec933f2e8423029f7236401aea04df
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
MMC_CAP_HW_RESET capability was only referring to host driver
capability to toggle eMMC RST_n pin so if the host driver is
unable to toggle this pin, it shouldn't advertise this capability
and in that case, we should exercise power cycling of the eMMC
card to reset it.
CRs-Fixed: 507926
Change-Id: Ia2c6ad5f5bb22cc0cd8cf3bd09835eda73c7a444
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Some of the time consuming operations such as BKOPS, SANITIZE, CACHE
flush/off use the SWITCH command (CMD6) but as these operations don't
have card specification defined timeout for completion, we may see
timeout errors if card doesn't complete the operation within the SW
defined timeout. If SW defined timeout is hit, above operations are
considered to be failed and no real recovery mechanism is implemented
after timeout.
Most of the above operations (BKOPS/SANITIZE/CACHE flush/off) can be
interrupted by sending the HPI (High Priority Interrupt) command to card
if they taking longer than expected. This change adds the base support
which will these operations to be HPIed after timeout.
Change-Id: Ibd9061525756aaae656b1ceeeaed62e04fb80cce
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
The original intention of polling for BKOPS completion was to give
the card enough time to perform the BKOPS before it is runtime suspended.
But as the BKOPS completion polling was happening in a different
context, it may race with card runtime/platform suspend which is quite
difficult to fix. So instead of BKOPS polling, let the runtime suspend
get deferred if the BKOPS is running on the card. Also if BKOPS is running
when platform suspend is triggered, stop the BKOPS before suspending the
card.
CRs-Fixed: 489523
Change-Id: I21e524dc2da37c4985c210abfaca00a28049c651
Signed-off-by: Maya Erez <merez@codeaurora.org>
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Out of CPU time for the MMC context included into measured timeout. System
under heavy load will easily exceed out_of_int_time (typically 20 ms),
because the MMC context is not running and when it is back to running,
timeout already elapsed. In this case real card status checked again and
error reported for wrong card state only.
Change-Id: I0da3bd2e7d41e4933ad3b1333d7135705a1eafec
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
Host drivers can participate in clock scaling by registering
->notify_load host operation, which allows host driver to carry out
platform specific operations for further power savings or increasing
throughput based on whether load is LOW or HIGH respectively. This
can be applicable to non-ultra high speed cards as well so remove
the check for ultra high speed cards to initialize clock scaling.
Change-Id: Icaab9520135e384f5470db68b2f25c5cdce5663a
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
Due to stop transmission mechanism to handle high priority requests,
the update of clock scaling statistics is broken as the stop command
will re-enter host through mmc_start_request() and modifies ->start.busy
timestamp. If statistics are updated after sending stop command then
the duration of the interrupted command will be left unaccounted.
CRs-Fixed: 473385
Change-Id: Id671388efbfdd16981a262c0b1e5b95d119f51ae
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
Use kernel's ftrace support to capture MMC clock frequency
transitions which can be useful for debugging issues related
to power consumption.
Usage:
mount -t debugfs none /sys/kernel/debug
echo 1 > /sys/kernel/debug/tracing/events/mmc/mmc_clk/enable
cat /sys/kernel/debug/tracing/trace_pipe
Change-Id: I25c4ee39dcbe30e7665902a9f723a5a421b55ca3
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
This patch prints out the runtime-pm state of a device
on error conditions.
Change-Id: I2f981898a572e2c7baf2410f90013fa20d1dc3f0
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
According to eMMC specification, only commands of classes 0, 2, 4
are admitted while accessing RPMB partition. Still usage of any
other command other than CMD0, CMD6, CMD8, CMD12, CMD13, CMD15,
CMD18, CMD23, CMD25 is illegal.
If the MMC clock scaling algorithm decides to switch the clocks
while accessing RPMB partition it might need to send tuning
command (CMD21) which is illegal.
Since RPMB accesses are short and doesn't depend on throughput
bypass clock scaling while the current partion mode is RPMB.
The clock scaling statistics still take into account the duration
of access and hence able to respond quickly on the transfers made
after partition switch.
Change-Id: I422f2e6acb33ab97105944e3f7f90c3afb37ef47
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
With commit 9b0f5ecb "mmc: Add support to handle Urgent
data transfer request" runtime MMC clock gating is broken.
The implementation in the commit introduces a new stop
transmission sequence due to which the underlying host
drivers may not always call mmc_request_done(). The clock
gating reference count must be updated in such cases failing
which the clocks are never turned off even when MMC is idle
for long time.
Change-Id: Idb8ea495290f34edf0f311728d4d5ef8b2dc2d1f
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
Drop whitespace, unused Kconfigs, and bad Makefile entries. Undo
code movement, remove dead function, and delete entire files that
we don't compile that make our code divergent from upstream. No
functional difference.
Change-Id: I1150b3d4b317fb5180c5d26e2366dccb28a6bf43
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Current mmc stack doesn't use the framework provided by power
management subsystem. It doesn't let each device suspend itself
and the pm operations are solely handled by the platform driver.
This may lead to races, since the concurrency of pm framework is
not used. The pm core does its best to reduce the probability of
a race between system suspend/resume and runtime PM by
decrementing/incrementing the usage counters of respective
devices during system-pm operations.
Moreover, it disables runtime PM altogether after suspending the
device and re-enables the same on resume.
To avoid this, the parent child relationship between the platform,
mmc_host and mmc_card devices is used. In this case, the relation
is defined as,
mmc_card -> (child of) -> mmc_host -> (child of) -> platform_dev
Each device is now responsible for its power management.
* mmc_card
-> schedules the runtime-suspend
* mmc_host
-> actually suspends/resume the host & card i.e. invokes
mmc_[suspend/resume]_host
* pltform_dev
-> disables irqs
Typically, the card device serves as a trigger for scheduling the
runtime-suspend and invoking runtime-resume.
Two new runtime-pm functions have been introduced:
* mmc_rpm_hold
-> resumes the device passed as a parameter
* mmc_rpm_release
-> suspends the device passed as a parameter
The above two functions are invoked from the below contexts:
* mmc_rescan
* bkops
* mmc-queue
Change-Id: Icf9dd34a445abfaf8dbb974ab1255feeda2581c9
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
All this is useless diff from mainline, so undo the changes to
get us closer to mainline.
Change-Id: I782f4ac0f82aabda7a5a0f547982df26e67abe92
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
In order to improve read request latency, urgent notification allowed
anytime, when current or previous requests are existing in the mmc layer.
It is not allowed to stop following running requests:
- urgent request: block layer should serialize urgent request notification.
- read request: it can't be packed, therefore it is better
to wait for its completion.
- REQ_FUA: interruption and delay in such request will impact sync process
of upper layers.
Change-Id: Id7d1480cce2059c1f23a5f29ad8f74e858be1ee6
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
Signed-off-by: Maya Erez <merez@codeaurora.org>
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
Sometimes even SD cards doesn't respond to commands when the
card enters into some bad state due to errors. To recover from
this state, a power cycle is issued to the card and it is
reinitialized again.
Change-Id: I7f5990b1210f1d7d2b0c3da7f2d7b757809d1977
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Add mmc_power_cycle which can be used to power cycle for instance
SD-cards.
Change-Id: Id1561ec6524453a260525acadd1315475fac72be
Signed-off-by: Johan Rudholm <johan.rudholm@stericsson.com>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Wei WANG <wei_wang@realsil.com.cn>
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Kevin F. Haggerty
Francescodario Cuzzocrea
Ritesh Harjani
Sahitya Tummala
Linux Build Service Account
Konstantin Dorfman
Asutosh Das
Kevin Liu
Sujit Reddy Thumma
Maya Erez
Pratibhasagar V
Tatyana Brokhman
Subhash Jadavani
Stephen Boyd
Johan Rudholm