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>
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>
Add the "perf" sysfs node to mmc_host class dev instead of
adding to it's parent platform device inorder to make it
compatible for all platform drivers such as SDCC and SDHC.
Change-Id: Ie830ac218b242be7da63ef3b8082404a8f2f20f5
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Incorrect arguments were passed to strlcpy() which causes Manufacturer
information to be copied partially in the SDIO core layer code. Use
appropriate arguments to copy the string value properly.
CRs-Fixed: 434831
Change-Id: I4a70bfc8dff31b216a6097c08f824a1f1b002d5d
Signed-off-by: Pratibhasagar V <pratibha@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 function disables packing mode. Right now the only reason is
change in data direction.
Change-Id: I0f4edba3da93fde28cf47ac95754a95e411fa2af
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
Clock scaling requires the tuning and if the tuning command
is sent to the card in invalid state, tuning procedure will
fail.
With urgent request mechanism implemented, there is a chance
that clock scaling invoked when card is not in a proper state
to receive the tuning command.
This change checks the card state (by sending the status command)
before invoking the clock scaling request.
Change-Id: Icb71a8e74a9afdc70380a5901cd3d28931959e9c
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
We need to do all the packing related initialization when running
the test instead of in the test preparation to prevent a race condition
between FS requests and the test requests
CRs-Fixed: 430138
Change-Id: I0bc96d9faa823f3574623edd7948f141f0d40b79
Signed-off-by: Maya Erez <merez@codeaurora.org>
eMMC may have several hard partitions such as BOOT and RPMB in addition
to the main USER partition. On resume(if card is reinitialized), the
current hard partition is always switched to the default USER partition.
But this switch to default partition is not propagated to the MMC block
driver, which may have set the hard partition to any partition(BOOT/RPMB)
other than USER before suspend. After resume, the MMC block driver still
assumes it is accessing the previously set partition(BOOT/RPMB), and
instead overwrites the USER partition(the current selected partition on
the eMMC device). To prevent this, make MMC block driver aware of the
partition switches done as part of card reinitialization.
CRs-Fixed: 439313
Change-Id: I3e959101a1c56c1e6631da3d660f4b914e100503
Signed-off-by: Oluwafemi Adeyemi <aadeyemi@codeaurora.org>
Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
[subhashj@codeaurora.org: fixed trivial merge conflicts]
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
The eMMC 4.5 spec for RPMB accesses is not very clear on whether
user parition accesses can be allowed in the middle of RPMB accesses.
Due to this ambiguity, it turns out this is implementation defined
and certain cards support it while others do not.
In order to allow this feature to function across a wide variety of
cards, this patch takes the pessimistic approach and ensures that any
RPMB access is completed before user partition can be accessed.
Change-Id: I77959f462c874771a0a854d9a2bc48df446eff56
Signed-off-by: Krishna Konda <kkonda@codeaurora.org>
Signed-off-by: Oluwafemi Adeyemi <aadeyemi@codeaurora.org>
Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
[merez@codeaurora: fix conflicts due to changes in 3.14]
Signed-off-by: Maya Erez <merez@codeaurora.org>
[subhashj@codeaurora.org: fixed merge conflicts and fixed compilation
errors]
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
After completion of block write request, MMC block driver waits for the
card to come out of the programming state. If card doesn't come out of
the programming state in 10 mins, it would be considered as error
condition and card would reinitialized. But this 10 mins is just too huge
and if card is continuously stuck in programming state for 10 mins,
mmcqd thread would take increase the CPU load significantly as we are
continuously polling for the card status (by sending status commands).
This patch reduces this timeout from 10 mins to 30 secs which is quite
reasonable for all well-behaved cards.
Change-Id: I4e8eaf29c836a81419220f312ee867b0dd5cccc7
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
[merez@codeaurora.org: fix trivial conflicts]
Signed-off-by: Maya Erez <merez@codeaurora.org>
Packed commands causes higher latency since the completion of each
request is sent to the upper layer upon completion of the complete
packed request.
The benefit from this feature is card dependent. Some of the card
vendors do not have any benefit from using packed commands for random
requests. In case there is no benefit in random requests packing,
it is better to disable the packing to prevent this high latency.
This patch also add the new stop packing reason to the write packing
statistics.
Change-Id: I141887dcef2ceee14848634cc27c3c85f8edc7a5
Signed-off-by: Maya Erez <merez@codeaurora.org>
[merez@codeaurora.org: fix conflicts due to removal of BKOPS]
Signed-off-by: Maya Erez <merez@codeaurora.org>
Currently we have 4 mins timeout for the blocking BKOPs to complete
but we have seen instances where card is surprisingly taking even
longer time to complete background operations.
If card doesn't complete the BKOPs within specified timeout, we
will send the HPI command to interrupt the ongoing BKOPs.
Change-Id: I5df81bdfd9b19bee30a394ee0ff4390b292691d0
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
[merez@codeaurora.org: fix conflicts due to changes in 3.14]
Signed-off-by: Maya Erez <merez@codeaurora.org>
A race condition can occur while enabling clock scaling and removal
of the card. If the card is removed just after the host->card check
is successful then there could be NULL pointer dereference later.
Claim mmc host before card availability check to avoid this race
condition.
Change-Id: I6339cad5857732ec6b66280940cd6b8b7ed30614
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
Add sysfs attributes to allow dynamic control of clock scaling
parameters. These attributes are used to enable/disable clock
scaling at runtime and change the up_threshold, down_threshold,
and polling_interval values. Complete documentation for these
sysfs entries are provided at "Documentation/mmc/mmc-dev-attrs.txt".
Change-Id: I4753c75c3b3eeea91e93bceba7af2535b793612e
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Since the write packing is an eMMc4.5 feature, packing control
should also be activated only for eMMc4.5 cards.
Change-Id: If094658943a536f39afc814f6684c0dbb0806778
Signed-off-by: Maya Erez <merez@codeaurora.org>
The SD3.0/eMMC4.5/SDIO3.0 cards can support clock rates upto
200MHz (SDR104 or HS200 bus speed modes). For some workloads
like video playback it isn't necessary for these cards to run
at such high speed. Running at lower frequency, say 50MHz, in
such cases can still meet the deadlines for data transfers.
Scaling down the clock frequency dynamically has huge power
savings not only because the bus is running at lower frequency
but also has an advantage of scaling down the system core
voltage, if supported.
Provide an ondemand clock scaling support similar to cpufreq
ondemand governor having two thresholds, up_threshold and
down_threshold to decide whether to increase the frequency or
scale it down respectively. The sampling interval is in the
order of milliseconds and should be chosen by host drivers that
enable MMC_CAP2_CLK_SCALE capability to take advantage of clock
scaling. The sampling interval mainly depends on the the clock
switching delays and hence a host driver decision. If sampling
interval is too low frequent switching of frequencies can lead
to high power consumption and if sampling interval is too high,
the clock scaling logic would take long time to realize that the
underlying hardware (controller and card) is busy and scale up
the clocks.
Change-Id: I22a5054beec41b0b66b3bf030ddfcf284de448b3
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
[merez@codeaurora.org: fixed conflicts due to changes in 3.14]
Signed-off-by: Maya Erez <merez@codeaurora.org>
[venkatg@codeaurora.org: runtime pm related changes to
accommodate pm framework from 3.14 kernel]
Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
[subhashj@codeaurora.org: fixed merge conflicts and fixed compilation
errors]
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
sdio_reset_comm() function may be invoked by the SDIO card function
driver to execute soft reset of the card but this function currently
fails to reset the UHS SDIO cards.
This change fixes this issue by simply invoking SDIO power restore
function which is capable of resetting both UHS and non-UHS SDIO cards.
CRs-Fixed: 424685
Change-Id: I4f1d76a6bfc4bfec16661aedba85c45b601f24ac
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
[merez@codeaurora.org: fix trivial conflicts]
Signed-off-by: Maya Erez <merez@codeaurora.org>
Due to timing issues, the BKOPS test: Level 1 with HPI, might
not yield the expected scenario. In this case we wouldn't like
to have a FAILURE but to mark the test as a test that should be
re-run.
Change-Id: If47d7f9ce250c46249c5ddc061d8b808100d2f94
Signed-off-by: Yaniv Gardi <ygardi@codeaurora.org>
[merez@codeaurora.org: fix conflicts due to removal of BKOPS]
Signed-off-by: Maya Erez <merez@codeaurora.org>
This function belongs to the file mmc_block_test.c since
it is used only in this file.
Change-Id: Ia832da6341b3053f0e4825d711668a3642482221
Signed-off-by: Lee Susman <lsusman@codeaurora.org>
When a failure occurs while creating a device attribute,
we need to remove previously created attributes prior to deleting
the disk.
Change-Id: I01a8d4437f372abdf33230c34a73b5806e97188b
Signed-off-by: Maya Erez <merez@codeaurora.org>
[merez@codeaurora.org: fixed conflicts as BKOPS is not taken]
Signed-off-by: Maya Erez <merez@codeaurora.org>
Expose the packing control test.
Test the packing control feature under these scenarios:
- Packing expected: entering write packing state,
staying in write packing state.
- Packing not expected: not entering write packing state
when not supposed to.
- Mixed states: test the ability to shift from packing
to no-packing and back, and the opposite.
Change-Id: I5a93df8b5b7c48d355c3cc881699a3f9592914e6
Signed-off-by: Lee Susman <lsusman@codeaurora.org>
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
Expose the following packed commands tests:
- Test the write packed commands list preparation
- Simulate a returned error code
- Send an invalid packed command to the card
Change-Id: I23a15f94571da3ff9553a342dc37e1a8de6827c6
Signed-off-by: Lee Susman <lsusman@codeaurora.org>
Signed-off-by: Maya Erez <merez@codeaurora.org>
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
When hitting a stop potential packing event, we should zero
num_of_potential_packed_wr_reqs, so that the packing won't be
enabled too early.
Change-Id: I91d36765c4a50be0e2805cd07c58962fb87153c6
Signed-off-by: Maya Erez <merez@codeaurora.org>
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
The write packing statistics are used for the packed commands unit tests
in order to determine test success or failure
Change-Id: I5eea513991c794543fbb3d009d8b7db0b0912fc5
Signed-off-by: Maya Erez <merez@codeaurora.org>
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
[subhashj@codeaurora.org: fixed trivial merge conflicts]
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
The write packing control will ensure that read requests latency is
not increased due to long write packed commands.
The trigger for enabling the write packing is managing to pack several
write requests. The number of potential packed requests that will trigger
the packing can be configured via sysfs by writing the required value to:
/sys/block/<block_dev_name>/num_wr_reqs_to_start_packing.
The trigger for disabling the write packing is fetching a read request.
Change-Id: I22e8ab04cd9aca220678784c39306068a0996790
Signed-off-by: Maya Erez <merez@codeaurora.org>
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
[merez@codeaurora.org: fixed trivial conflicts]
Signed-off-by: Maya Erez <merez@codeaurora.org>
[subhashj@codeaurora.org: fixed trivial merge conflicts]
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
When the fault injection framework introduces an error to the data
block, the current code queries the SD card to find the number of
blocks actually programmed. This value would be as requested by the
generic block layer. So the entire request would be completed.
Say, request 0 is pulled from queue and submitted. When this is being
processed, request 1 is pulled from queue and prepared. Request 0
though is successful, fault-injection framework injects an error
and modifies the bytes_xferred variable to a random value less than
requested transfer. Request 1 is not processed and during the handling
of error, the SD card is queried for the actual bytes programmed. This
would be the correct value. Thus blk_end_request would complete
this request and the control would return to fetch request 2. In this
process, request 1 is not processed at all and the application waits
indefinitely for request 1 to be processed. No further requests are
issued to the queue.
This patch identifies, if the fault injection-framework has inserted an
error to this request and doesn't query the card and uses
bytes_xferred to complete the request.
Change-Id: I496802e244745bc7550402027a594d967cf7b756
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
[subhashj@codeaurora.org: fixed trivial merge conflicts]
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
This reverts the if/else part of
4466903481. We don't know why it
was done though and this should probably be dropped after testing.
Change-Id: Ie453df2f62b6716c6c0aa83dd4822b8555c4e555
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
[merez@codeaurora.org: fix conflicts]
Signed-off-by: Maya Erez <merez@codeaurora.org>
[subhashj@codeaurora.org: fixed merge conflicts]
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
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>
