Ensure clocks are always enabled before any interaction with the
host controller driver. This makes sure that there is no race
between host execution and the core layer turning off clocks
in different context with clock gating framework.
Change-Id: Ib47d0641f02c4390d26567102ee178beaf63516c
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Per Forlin <per.forlin@stericsson.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
[sboyd: Keep non-upstreamed bits for sdio.c]
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
mmcq performance numbers are not captured since asynchronous
MMC request support got added in MMC block driver. So printing
out these numbers (which are all zeros) just adds confusion.
This patch removes the printing of mmcq performance numbers
statistics.
CRs-Fixed: 364206
Change-Id: I7213b11c8e9e055894c9902af7e975de3be1c519
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
MMC_CLKGATE feature can be enabled for Atheros AR6003 cards as
the host supports asynchronous acitivity notification when the
clocks are off.
Change-Id: Ieff00382894a0841496776dc6a6b1db53e204d6d
Signed-off-by: Krishna Konda <kkonda@codeaurora.org>
Some INAND MCP devices advertise incorrect data timeout values.
This leads to data timeout errors on the platform. So, add a quirk
for such devices to facilitate proper functionality.
CRs-Fixed: 355347
Change-Id: If4fdd2724dc407450da8529222efca7ee94f50df
Signed-off-by: Pratibhasagar V <pratibha@codeaurora.org>
[merez@codeaurora.org: fix num of quirk to an additional quirk on 3.14]
Signed-off-by: Maya Erez <merez@codeaurora.org>
[subhashj@codeaurora.org: fixed trivial merge conflicts]
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
test->highmem can be NULL if no page can be allocated.
In this case don't try to free it which can cause NULL
pointer dereference crash.
Change-Id: I6c31a265fd801dfc4169530e3f39ffcf6590f5a8
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
Currently performance numbers are captured for each SDCC
transfers unconditionally which may add the overhead and
could reduce the SDCC read/write throughput numbers.
This change adds additional control for enabling/disabling the
capturing of performance numbers at runtime. We already have sysfs
entry named "perf" for msm sdcc devices. Currently setting this
entry to 0 clears the performance statistics. But now we are
changing the definition of this entry as mentioned below:
Disable performance capturing and clear the performance statistics:
"echo 0 > /sys/devices/platform/msm_sdcc.<n>/perf"
Enable performance capturing:
"echo 1 > /sys/devices/platform/msm_sdcc.<n>/perf"
CRs-fixed: 345170
Change-Id: I3ab9288fd87cc8a8ada6c0c3d066cac4f68d79b7
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Profiling code is added to measure read, write times for
the MMC requests at various MMC layers. Profiling is done
at the MMC queue and at the driver level. This information
can be viewed through a sysfs entry called perf.
Change-Id: I7c65bfe25a1f7774e3a9abf1f9539e690b3718ec
Signed-off-by: Aparna Mallavarapu <aparnam@codeaurora.org>
Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
[subhashj@codeaurora.org: fixed trivial merge conflict]
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
MMC_CLKGATE feature can be enabled for Volans cards as
the host supports asynchronous acitivity notification
when the clocks are off.
Change-Id: Ic6cfa7fb2e713dcf1d2c6b2ae9df9cf0394f8c4a
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
[merez@codeaurora.org: fix trivial conflicts]
Signed-off-by: Maya Erez <merez@codeaurora.org>
mmc_set_ios() is used by host drivers during suspend/resume
routines in indirect way i.e., by calling host->ops->set_ios().
But now with MMC_CLKGATE enabled, mmc_set_ios() also updates
host->clk_gated flag. So export this API so that host controller
drivers can use it.
Change-Id: Ib0c177635bb8d87ba68c98e08b8d940c73f2b80c
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
[merez@codeaurora.org: fix trivial conflicts]
Signed-off-by: Maya Erez <merez@codeaurora.org>
mmc_resume_host() is called during resume (runtime or system) which calls
1. mmc_power_up
2. mmc_select_voltage
3. host->bus_ops->resume() (mmc_sd_resume())
mmc_sd_resume() ultimately calls mmc_sd_init_card() to initialize the
SD card. But let's say if mmc_sd_init_card() fails during the
execute_tuning(). At this point, host controller timing is changed
to SDR104/SDR50 mode and host clock will also be > 100 MHz.
If there is an error returned by mmc_sd_init_card() and
if CONFIG_MMC_PARANOID_SD_INIT defined, it retries by calling
mmc_sd_init_card() without making sure that host controller timing
and clock be initialized again. This may cause the further
mmc_sd_init_card() also to fail.
To fix this, mmc_sd_resume() should call mmc_power_up()
and mmc_select_voltage() before retrying.
Change-Id: I8de39ea547fa0d5eca478719a4cf9255b6652503
[merez@codeaurora.org: changes already present in core.h and core.c]
Signed-off-by: Maya Erez <merez@codeaurora.org>
[venkatg@codeaurora.org: Fix args for mmc_power_up and mmc_select_voltage
as used in 3.14 kernel]
Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
[subhashj@codeaurora.org: fixed merge conflicts]
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
SDCC runtime suspend can race with mmc_rescan causing deadlock.
The call flow would be this:
1) When runtime suspend is triggered:
msmsdcc_runtime_suspend()
-> mmc_suspend_host()
-> mmc_flush_scheduled_work()
2) mmc_flush_schedule_work() waits for mmc_rescan() work
to be completed if it is already in runqueue.
3) When mmc_rescan() is scheduled to run:
mmc_claim_host()
-> msmsdcc_enable()
->pm_runtime_get_sync()
4) pm_runtime_get_sync() waits for runtime_suspend to complete,
and hence cause two threads to wait upon each other.
Fix this deadlock by aborting runtime suspend when mmc_rescan
is scheduled.
CRs-Fixed: 326610
Change-Id: I4ca88651f80f5a1bfccb6e0c07e3ea83fadcdc57
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
msleep of any delay less than 20ms (or 2 jiffies) would
give an unpredictable delay (most of the times as ~20ms).
Use usleep_range in mmc_delay() for delays less than two jiffies.
Change-Id: I7cf22532af2b4048afccf07a5aeba89d808799f0
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
Qualcomm SDCC controller supports minimum SD clock frequency
which is required for card initialization. This information is
exported through platform data for each SDCC controller. There is
no need of retrying higher frequencies than the minimum supported
by controller for Qualcomm chipsets which inturn add delay in
detection process if there is no card during suspend/resume cycles.
Hence, skip multiple frequency retries.
Change-Id: If1532213aaf265bdb4f5ddf68d9f70005ed97037
Signed-off-by: Sujith Reddy Thumma <sthumma@codeaurora.org>
[subhashj@codeaurora.org: fixed trivial merge conflicts and
compilation error]
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
When SD/MMC card is removed without unmounting and
then reinserted again while gendisk is freed. Partition
invalidation and deletion may take more than 10secs during
which SDCC controller can suspend due to runtime pm functionality.
Once the block layer activity is done it claims host to detach card
from MMC bus which triggers SDCC resume. As the host->card is
NULL already there is a BUG_ON hit in mmc_sd_resume(). Fix this
by claiming host even before we free host->card.
CRs-Fixed: 284262
Signed-off-by: Sujith Reddy Thumma <sthumma@codeaurora.org>
(cherry picked from commit 5eed6a9778440ef512f597b43368337a7ef9438b)
Change-Id: I6b58aab1865a93a025fd9912200ab0beea21be92
Signed-off-by: Shruthi Krishna <skrish@codeaurora.org>
Signed-off-by: David Brown <davidb@codeaurora.org>
MMC core reads SEC_COUNT information from EXT_CSD register and assumes
that the card supports sector access mode. Some eMMC cards (<=2GB) do not
support this mode even though they have SEC_COUNT value defined, causing
failure while populating extended partitions. Sector/Byte access mode
information is stored in OCR register. Hence, read OCR bit 30 and then
confirm it with SEC_COUNT value to know whether the card supports sector
access mode or byte access mode.
Change-Id: Ifdfff35309e8667cd2c2ac2761b9a708d5b785d3
Signed-off-by: Sujith Reddy Thumma <sthumma@codeaurora.org>
Qualcomm-SDIO client on MDM contains NULL tuple for all SDIO functions 1 to 7
and doesn't contain any valid data. This patch is a temporary software
workaround (not to read CIS if it is NULL tuple) until the hardware bug is
resolved. The device ID 0x23F0 is for the SDIO client core on MDM8220. The
device ID 0x23F1 is used for msm8660_charm.
Change-Id: I82f44d313b3d499462977a0a9bbc0759f489ae95
Signed-off-by: Maya Erez <merez@codeaurora.org>
Signed-off-by: Murali Palnati <palnatim@codeaurora.org>
Signed-off-by: Raj Kushwaha <rajk@codeaurora.org>
[sboyd: Squash in two other device id patches]
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
There is a possible race with mmc_claim_host() in mmc_sd_suspend()/
mmc_suspend() and mmc_claim_host() in mmc_blk_issue_rq() when runtime
pm is enabled. Fix this by blocking processing of requests until the
previous runtime suspend is processed and then resume as part of
msmsdcc_enable(). Previous fix has card detection failure as a side effect
during resume.
Change-Id: I9cb31269638d9db4e630eb22b973a5335af1bda4
Signed-off-by: Sujith Reddy Thumma <sthumma@codeaurora.org>
[sboyd: Dropped msm driver change]
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
[subhashj@codeaurora.org: fixed trivial merge conflict]
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
The current code doesn't set any timeout value for bus test commands
CMD19 and CMD14. This fails bus test because the controller returns
DATATIMEOUT error for these commands. Fix the bus test timeout value
to 1ms for all cards.
Change-Id: I12446e094302f51853cc0c56a5c13b4a6a46d8cb
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
[merez@codeaurora.org: fix conflict due to change of code]
Signed-off-by: Maya Erez <merez@codeaurora.org>
When the clock scaling state is changed from MMC_LOAD_LOW to
MMC_LOAD_HIGH, the clocks are first scaled up and then tuning
is performed. But in case of tuning failure, the current code
does nothing but still retain the previous clock scale stats
(state and curr_freq within struct clk_scaling). Hence, correct
it to scale down the clocks in case of tuning failure so that
clock scaling stats reflect the correct status. This also helps
proceed with data transfers at lower clock rate in such cases.
Change-Id: I7e9379d1e3ddc863132af31019604c22a42f8d59
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
[subhashj@codeaurora.org: fixed compilation error]
Signed-off-by: Subhash Jadavani <subhashj@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>
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>
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>
[merez@codeaurora.org: fix trivial conflicts]
Signed-off-by: Maya Erez <merez@codeaurora.org>
Currently, the card state is not being set as removed, even
when the card is actually removed. We still wait for the
next request to fail and then check the error and set the
card to be removed.
With the new runtime-pm in place, the card device would be
removed on physical removal of card and the corresponding
parent would be suspended as well. Hence, when the queue is
flushed during clean-up, mmc_rpm_hold would be invoked,
which would fail, since the runtime-pm was disabled when the
card device was removed. Thus, it won't resume the card/host/
platform device. The request would continue and since the
controller is in suspended state nasty things would happen.
This patch sets the card as removed during mmc_sd_detect
itself, so that when a clean-up of queue happens during
card removal, it is known that the card has been removed
and the request is errored out there itself.
Change-Id: Id5022f8d7db43750edf137d4293796615b56ae36
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
mmc_blk_suspend() is triggered when system is going into suspend which
then waits for the mmcqd thread (which processes active MMC transfer
requests) to complete all queued transfer requests but if mmcqd has
multiple requests to be processed at this point, mmc_blk_suspend() may
very well sleep for duration longer than DPM (Device Power Management)
timeout (currently 12 sec) causing the DPM timeout bug.
To fix this issue, mmc_blk_suspend() checks if there are any more pending
MMC requests in progress or not and if there are any, it returns error
which should abort the ongoing system suspend.
CRs-Fixed: 439192
Change-Id: Ic7ba2f013d10a1952c30ea2ed93f74b831fcc27d
[subhashj@codeaurora.org: fixed trivial merge conflicts]
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Limiting the max frequency supported by host controller
to a certain value can be useful for testing power consumption
at various frequencies that are supported by the host.
Note: If the card supports less than desired value then the
frequency of operation would be limited to that frequency.
Usage:
mount -t debugfs none /sys/kernel/debug
echo <desired_frequency> > /sys/kernel/debug/mmcX/max_clock
cat /sys/kernel/debug/mmcX/max_clock
Change-Id: I9e9a7e368f56d8e16548780288211bd8775fd048
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
Currently, bus frequency is set during the card initialization and
never changed until a new card is inserted. In some low power use
cases, scaling the clock frequencies while the card is in transfer
state would allow power savings. This change allows bus frequency
to be changed after the card initialization.
Change-Id: Iac064221199f69d162d91f5311becd735c15700a
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
[merez@codeaurora.org: remove mmc and sd ops_unsafe settings as they are not in 3.14]
Signed-off-by: Maya Erez <merez@codeaurora.org>
[venkatg@codeaurora.org: Fix refactor of mmc_card_* functions as used
in 3.14 kernel]
Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
[subhashj@codeaurora.org: fixed trivial merge conflicts & fixed
compilation error]
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
In mmc_wait_for_req_done() function, change the call wait_for_completion()
to wait_for_compltion_io(). This change makes the kernel account for
wait time as I/O wait and through another configuration, this io wait
is treated as busy which makes the acpu clock to scale up.
Change-Id: Iebdc7b1b22871bf845f10a55e2272816c72d9964
Signed-off-by: Murali Palnati <palnatim@codeaurora.org>
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Rate limit sdhci_dumpregs() prints to avoid unnecessary
and exessive logging which can sometimes lead to watchdog
timeouts (especially due to bad cards).
Change-Id: Ib6be6d563e47c2d2e9e1b6b0410c2c45712a9b17
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Add a new dts entry to define the CPU affinity in order to maintain
the IRQ pm_qos (Quality of Service) for targets that don't have little
cluster and allow setting the pm_qos to the little cluster,
to improve its performance.
Change-Id: Icf6125066d96331392d98a387974e54c96553306
Signed-off-by: Vince Leung <vincentl@codeaurora.org>
Signed-off-by: Maya Erez <merez@codeaurora.org>
SDCC AXI master uses 32-bit addressing so there's no need to use
64-bit descriptors. Using 32-bit descriptors instead will reduce
the memory footprint.
This change masks the 64-bit capability to force 32-bit ADMA
descriptors.
CRs-Fixed: 719303
Change-Id: Ifb8095763136bbc795227bdfcb346d1e1fae42c7
Signed-off-by: Gilad Broner <gbroner@codeaurora.org>
SDCC5 controller doesn't advertise 1.8v capability by default.
Dual voltage capability is required for SD3.0 support. Add this
capability for controllers that support this based on
device tree configuration.
Change-Id: Ie4cd6db2e7230bc22cd393c8e37d99f49c777cd0
Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
With some devices like QRD SKUK, SD card could not support
hotplug as there is no cd-gpio, and also could not use polling
way due to power comsumption. So add nonhotplug to meet such
requirement and when SD card lost or removed manually, device
will not crash until next reboot process to detect SD card.
Change-Id: I318d3db72fc09248c5dada2fb6d69ade1bbf85cb
Signed-off-by: Guoping Yu <guopingy@codeaurora.org>
With some devices, SD card could not support hotplug as there is
no cd-gpio, and also could not use polling way due to power
comsumption. So add nonhotplug to meet such requirement and when
SD card lost or removed manually, device will not crash until
next reboot process to detect SD card.
Change-Id: Ie8ea8ec57015f36689a119249003eeaa48391393
Signed-off-by: Guoping Yu <guopingy@codeaurora.org>
[subhashj@codeaurora.org: fixed minor merge conflict]
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
The platform_get_resource API may return NULL, hence check
the return value before using the mapped memory.
Change-Id: I28741554f8e1b5843671ee0d6b08bdcf8e4469c9
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
8K is the max descriptors supported by the hardware per transfer.
On normal use cases we never use that many descriptors even if
the memory is extremely fragmented. The memory allocated for these
descriptors are never freed hence wasting memory otherwise
available for the system. Reduce the max descriptors to 512 to save
memory (128K with 8K descriptors vs 8K with 512 descriptors) and
still support maximum performance.
CRs-fixed: 684185
Change-Id: Ib57ce03834d741c0fda4195a58d6b287ee9fb0a0
Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
Instrument the sdhci driver with tracepoints to aid in
debugging issues and identifying latencies in the following
path:
* CMD completion
* DATA completion
* DMA preparation
* Post DMA cleanup
Change-Id: Ie8cd0c2fb6c1bd6ab13883123be021081f8b8f78
Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
[subhashj@codeaurora.org: fixed minor merge conflict]
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
The current vote applies to all CPUs and hence may have power
impact, especially when there are more number of CPUs. The new
IRQ specific QoS request shall update the vote only for one
CPU to which the IRQ's smp_affinity attribute is set to.
Change-Id: I55298f729949c39ebfa3eecd4746d77e40cb2e5c
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Program CORE_CSR_CDC_DELAY_CFG for hardware recommended 1.25ns delay.
We may see data CRC errors if it's programmed for any other delay
value.
CRs-Fixed: 683894
Change-Id: Id7de28b7b9222c35e6b419e416f72bd8f98cbaf8
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
In HS400 mode, command line is still operated in SDR mode and not
DDR mode like data lines. So in order to correctly process command
responses, the hardware needs to be set appropriately or else there
will command crc or similar errors due to incorrect sampling of the
response.
Change-Id: I426ff4fc4798afae254d11a608c800dc0b7bf765
Signed-off-by: Krishna Konda <kkonda@codeaurora.org>
The newer msm sdhci's cores use a different DLL hardware for HS400.
Update the configuration and calibration of the newer DLL block.
The HS400 DLL block used previously is CDC LP 533 and requires
programming multiple registers and waiting for configuration to
complete and then enable it. It has about 18 register writes and
two register reads.
The newer HS400 DLL block is SDC4 DLL and requires two register
writes for configuration and one register read to confirm that it
is initialized. There is an additional register write to enable
the power save mode for SDC4 DLL block.
Change-Id: I20ddeaee9309c43cd51bebdfc02d70553c9d2a87
Signed-off-by: Krishna Konda <kkonda@codeaurora.org>
Set up the card detect GPIO in active configuration before
configuring it as an IRQ. Otherwise, it can be in some
weird/inconsistent state resulting in flood of interrupts.
Change-Id: I8f2344a72acbd48df745cc9b2602fe4ac6f034d4
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
The intention of sdhci_msm_probe() was to wait up to 1ms for
CORE_SW_RST to be set, but only a 10us timeout was passed to
readl_poll_timeout().
Correct the timeout value to be 1ms, and decrease the sleep
time between read attempts to only 10us so that it's less
than the expected wait time of 40us.
Change-Id: I7007a68232bfba76409e2dbae3060622fa5c1913
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
On fast path, waiting for 1ms interval to poll registers cause
performance degradation. Also having 1ms delays for polling with
interrupts disabled cause considerable system latencies, hence
poll at 1us interval.
Change-Id: I40113ccf56050b3c46604112846e9b37b254d2be
Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
For controllers that doesn't support card insertion/removal i.e.,
when the quirk SDHCI_QUIRK_BROKEN_CARD_DETECTION is defined,
card_event() host op must not rely on present state register
to check the card's status.
CRs-fixed: 644221
Change-Id: Icff6db0d8fe17f01cf751896ae09aee215edc548
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
The commit 'e2598c - mmc: sdhci-msm: improve tuning process'
introduces NULL pointer dereference bug for SD 3.0 cards
when all the tuning phases pass. It uses mmc_card_mmc(card)
for checking the card type but card is initialized after
tuning is done for SD card and thus resulting in NULL
pointer dereference issue.
CRs-fixed: 640424
Change-Id: I59a8d5f017243d8391269bc98998bb37fc44f685
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
As of now we ignore CRC/INDEX command failures to tuning command
and still wait for data from card but in case the card did not
receive the command, it won't send the data. This is causing
software request timeout for tuning commands. Hence, software
must not ignore such cmd errors for tuning commands but end the
request immediately after resetting the controller for both CMD
and DATA. Also, wait for 146 MCLK cycles for card to send out the
data and thus to move to transfer state. Its corresponding phase must
also be considered as bad phase.
CRs-fixed: 625855
Change-Id: Ic8462dd9c67e4f18a3ce73d972591772be8c6d10
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
[subhashj@codeaurora.org: fixed minor merge conflict]
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
In newer hardware, the tuning process is not able to always
find a reliable phase to use for sampling data. This is mostly
due to hardware. This problem manifests itself as all successful
tuning phases, which means that the phase choosen could be a bad
one but is not identified as such at the time of tuning. So in
order to work around this, rely on optional drive types implemented
by the eMMC card, in addition to the mandatory drive type (50 ohm).
By using drive types supported by the card, when all phases are
sucessful in tuning, change drive type to a different value in the
list of supported drive types and retune. This will continue for all
tuning phases until a valid one is found. After that the drive type
is reset to the default one, if changed.
Change-Id: I348fb30daa43d97c58f83f7e4a22019f94ef4954
Signed-off-by: Krishna Konda <kkonda@codeaurora.org>
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
[venkatg@codeaurora.org: rename cmd_timeout_ms to busy_timeout as
part of 3.14 kernel upgrade]
Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
[subhashj@codeaurora.org: fixed minor merge conflict & compilation
error]
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
