As per specification, auto cmd error status register is valid only
when auto cmd error bit is set in Error interrupt status register.
CRs-fixed: 515513
Change-Id: Id1013e1705d8efdba0171dcad14f783607d38ef3
Signed-off-by: Sahitya Tummala <stummala@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>
There is race between sdhci_tasklet_finish()
and sdhci_stop_request(): when the request is finished before
stop flow called, error returned.
Change-Id: Ic036feae925b2e9e5435e44f97b24a179547bf49
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>
HS400 bus speed mode also requires tuning to be performed as done in
HS200 mode. Add the capability in host layer to perform tuning for
HS400 too.
Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
HS400 is a new bus speed mode introduced in eMMC5.0 specification. This
patch adds the capability in mmc core to switch to HS400 mode when both
the host and the card supports it.
Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
The bus speed selection code in mmc_card_init() is convoluted, refactor
the code to simplify this and make it simpler for adding new bus speed
capabilities.
Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
Provide sysfs tunables to defer PM QoS vote of default value so that
back-to-back requests wouldn't suffer from latencies caused by CPU
power collapse transition states.
Change-Id: I7180c68c1f13240faa5f432335d72e7f6b198183
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
PM QoS vote of default value mean that the CPU is allowed to move
into deepest low power mode whenever possible. Currently, if there
are back-to-back MMC requests, with a short delay, the PM QoS vote
to default value is done immediately which cause the immediate
request to have high latency as the CPU might have idle'd and moved
to deepest low power mode. To avoid this defer the PM QoS vote till
a defined timeout (pm_qos_timeout_us), so that back-to-back requests
may not suffer from additional latencies.
In addition, if the load on MMC is low, the additional latency may be
sustainable. Hence, aggressively release the vote in order to achieve
additional power savings.
CRs-Fixed: 501712
Change-Id: I82166b0ce9416eb0d519f7da26e5a96956093cb2
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
When the card is removed in mmc_sd_detect(), the card status is
marked as runtime suspended and this asynchronously triggers
runtime suspend of it's parent mmc_host class device. The
mmc_power_off() will be called from runtime suspend handler and
it races with mmc_power_off() within mmc_sd_detect(). Fix this by
acquiring mutex at the host driver when set_ios host operation
is invoked and until it is done.
CRs-fixed: 513141
Change-Id: I4e7afbe966ecbcc2c8bf746fb6cffc64b7cf252e
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
As "bkops_busy" flag is no longer used, remove it from the mmc_command
structure.
Change-Id: Icd405ba4879c5dfc915eba9bf821633fdd87fbb6
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 driver currently uses fixed timeout value from capabilities
register (bit 5-0) to calculate the timeout which is advertized
as 50MHz. But the driver uses SDHCI_QUIRK2_ALWAYS_USE_BASE_CLOCK
and controls the base clock (MCLK) directly. So during card
initialization, the frequency would be 400KHz but still timeout
is calculated at 50MHz which is wrong. This patch fixes this by
using the current base clock frequency to calculate the timeout.
The controller internally multiplies the timeout control register
value by 4 with the assumption that driver always uses fixed
timeout clock value from capabilities register. Add a quirk
SDHCI_QUIRK2_DIVIDE_TOUT_BY_4 to avoid this multiplicaiton in
case base clock is used for timeout calculation.
CRs-fixed: 498159
Change-Id: I503fd16132bf17e590239997d6970b9b730d4202
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
To handle card-detect of SD/MMC slot pins we need generic flags to
specify their polarity.
Change-Id: I8d71ec888931e7ec6adaac9a5623c003dde78a87
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
At the moment only POWER_OFF_SHORT is sent to the device in case the host
is suspended. This patch adds the support of sending POWER_OFF_LONG
notification in case the device is powered off.
According to device vendors the POWER_OFF_LONG notification will shorten
the initialization time of the eMMC card during next boot up.
Change-Id: I3c6f224398450cf10463cbb316613fd430d1e8d2
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
MMC Host driver might want to use the mmc_host_may_gate_card() API
to know whether the clock can be gated to the card or not hence
export this function for usage outside its current scope.
Change-Id: I9ec4173063e2505eca179161cdf8cda033a3fd4b
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
SDIO 3.0 specification has added the support for asynchronous interrupt
period during which card allows the clock to be gated off. Host needs
to first read the "Support Asynchronous Interrupt" bit in CCCR register
space to check if the card supports the feature or not. If yes and if
the host wants to enable the feature, host needs to write '1' to
"Enable Asynchronous Interrupt" bit in CCCR register space.
This change allows the host controller driver to control whether to enable
the asynchronous interrupt in card or not and if the asynchronous interrupt
is enabled then clock gating feature would be enabled for such cards.
Change-Id: I678cffb63af6a2013640a5eafa6ce9bfad8a51d6
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>
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>
The MSM SDHCI controller defines the usage of 0xF in data
timeout counter register (0x2E) which is actually a reserved
bit as per specification. This would result in maximum of
5.3 secs timeout value. For some buggy SD cards, the core
layer wants to set the data timeout to 3 secs and on our MSM
SDHCI if we configure data timeout counter value to 0xE,
then we would get only 2.67 secs. Observed data timeout errors
for CMD25 on SDR104 card. Hence program data timeout counter to
0xF, to achieve at least 3 secs timeout value.
CRs-fixed: 470661
Change-Id: Ie1e192eb9c38ca3922bb1f518073a8ff0cb57f0c
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
This helps check the controller timeout logic in case of data
timeout errors.
Change-Id: Ia30757192e49865698c5f52940e1dc5d97746185
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
If preset value (bit 15) is enabled in sdhci host control2
register (0x3E), then the preset value registers(0x6F-0x60)
would be used for some of the settings such as clock and
drive strength. These are HW initialized registers and are
not properly initialized by MSM SDHCI controller. This is
resulting in low throughput for some of the modes such as
DDR50/SDR50. Hence, do not enable it for MSM SDHCI.
CRs-fixed: 474518
Change-Id: Iee1241355d14e6bcebc66c3a43abf1ec94d869c3
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Ignore data timeout error for R1B commands as there will be no
data associated and the busy timeout value for these commands
could be lager than the maximum timeout value that controller
can handle.
CRs-fixed: 473435
Change-Id: I61f7463cf09648ad9fab83437abf5004effc7758
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
mmc_signal_sdio_irq() should only be called when the function
driver registers for IRQ notification. In case, if any host
driver recieves a spurious interrupt and call mmc_signal_sdio_irq(),
ignore waking up uninitialized sdio irq thread.
CRs-Fixed: 472609
Change-Id: I831717fe80918538a18cc1f2300fe7fe2817c70f
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
Signed-off-by: Krishna Konda <kkonda@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>
The SDHCi driver by default specifies a parameter that causes the
core layer to calculate a max discard value which will be set on the
mmc queue. Unfortunately the value calculated because of this would
be very small compared to what comes in by default. As a result of
this, any secure discard kind of operations are very slow.
Instead add quirk so that any SDHCi hosts that would like to use
the default value can do so.
Change-Id: Ifa1343c3e7f14b031da30b06203a8831ba544889
Signed-off-by: Krishna Konda <kkonda@codeaurora.org>
Add support for enabling clock scaling feature and indicate
the same to MMC core layer by setting the capability
MMC_CAP2_CLK_SCALE.
Change-Id: I24f144d3f727160c302966888fb439b3a39a0dde
Signed-off-by: Sahitya Tummala <stummala@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>
pre_req() runs dma_map_sg() post_req() runs dma_unmap_sg.
If not calling pre_req() before sdhci_request(), request()
will prepare the cache just like it did it before.
It is optional to use pre_req() and post_req().
Change-Id: I32cabddc4ec824515fa9ba4ff0ad7bce3679a3ef
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Patch-mainline: linux-mmc @ 16/04/11, 09:43
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>
Vote for PM QOS by specifying the acceptable CPU to DMA latency
so that system can enter into the possible power states without
affecting the SDHC performance.
Change-Id: I5fcf9aa93da690c6e64ab70ea5b039ca663c80ad
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Some platform drivers support more than 128 adma descriptors
and allows more than 512KB maximum request size per transfer.
Add a callback to get maximum supported adma descriptors from
platform driver instead of limiting host capabilities to
128 descriptors.
Change-Id: I0ac0ffbd0e792a76931e21b321b39c35195ac8d6
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
MSM SDHCI controller doesn't support tuning as specified by the
Standard Host Controller 3.0 spec. As a result of which,
CMD CRC errors are expected for tuning commands. Hence, add a
new quirk SDHCI_QUIRK2_IGNORE_CMDCRC_FOR_TUNING to ignore
those errors for tuning commands.
Change-Id: Id43d300bf8fabea921c80931fbf45cd3782ff3fa
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Initial version of Qualcomm SDHC has the following two h/w
issues. This patch adds s/w workarounds for the same.
H/W issue: Read Transfer Active/ Write Transfer Active may be not
de-asserted after end of transaction.
S/W workaround: Set Software Reset for DAT line in Software Reset
Register (Bit 2).
Added a quirk SDHCI_QUIRK2_RDWR_TX_ACTIVE_EOT to enable this workaround.
H/W issue: Slow interrupt clearance at 400KHz may cause host controller
driver interrupt handler to be called twice.
S/W Workaround: Add 40us delay in interrupt handler when operating at
initialization frequency(400KHz).
Added a quirk SDHCI_QUIRK2_SLOW_INT_CLR to enable this workaround.
Change-Id: I8b4062f101085adadd66560f77b98b04d75cb836
Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
During MSM 3.4 kernel upgrade the changes to already existing
files sdhci.c and sdhci.h were missed out. As a result of which,
these files are still pointing to 3.0 changes. This commit adds
those missing changes back.
Change-Id: Ibfabd11948dcf90db5b79688b694ff889bd55a60
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Urgent request notification stops currently running transaction
on bus.
In order to decrease a latency of a prioritized requests (aka Urgent
request), we might want to stop the transmission of a running "low
priority" request in order to handle the Urgent request. The urgency of
the request is decided by the block layer I/O scheduler. When the block
layer notifies the MMC layer of an urgent request and if the MMC layer is
blocked on current request to complete, it will be woken up.
The decision on whether to stop an ongoing transfer is taken according to
several parameters, one of them being the number of bytes already
transferred for ongoing transfer by host controller so far.
To calculate how many bytes were successfully programmed before stop,
CORRECTLY_PRG_SECTORS_NUM[245:242] parsed from EXT_CSD register. The
remainder of stopped request (and next prepared request in case it
exists) re-inserted back to the I/O scheduler to be handled after the
completion of the urgent request.
In case it is decided not to stop the ongoing transfer, MMC context will
wait for normal completion of the ongoing transfer, then already prepared
next request (if it exists) will be re-inserted back into block layer and
the urgent request fetched.
URGENT_REQUEST handling has following dependencies:
1. Host controller driver should support mmc_host op named "stop_request"
2. Block I/O scheduler should support re-insert API
3. eMMC card should support HPI (High Priority Interrupt) command
If any of the above dependencies are not met then urgent request mechanism
will not become operational.
Change-Id: Ic3fa1ca9463cc8991aefee940d8bfddf76c111d3
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
This change will prevent packing of a request marked with REQ_FUA flag,
because it has the same semantics as REQ_FLUSH. Also packing statistics are
updated with FUA stop reason.
Change-Id: Iaad37044ec43f93e898ed0c011b0bce7b91ae13d
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
The migration to kernel3.7 caused duplication in the caps2
definition.
This patch sets a unique value for each caps2 flag.
Change-Id: I62f4e25553877cfb25c3e1ceb8aeafab61abc499
Signed-off-by: Maya Erez <merez@codeaurora.org>
Linux Build Service Account
Sahitya Tummala
Asutosh Das
Konstantin Dorfman
Pratibhasagar V
Venkat Gopalakrishnan
Sujit Reddy Thumma
Subhash Jadavani
Tatyana Brokhman
Maya Erez
Krishna Konda
Shawn Guo
Stephen Boyd