Fix a race condition that can lead to null pointer dereference
while the MMC transfers are going on.
1) mmc_request_done() -> mmc_wait_for_data_done ->
step1: update is_done_rcv
step2: wake_up sleeping thread (mmcqd) waiting for is_done_rcv
2) mmcqd -> mmc_wait_for_data_req_done
step4: wait for is_done_rcv or is_new_req
step5: is_new_req set from block layer context and mmcqd
is woken up
step6: let's say step1 is done, so complete the current request
step7: fetch new request and issue to host layer
step8: fetch one more request and wait for previous request to
complete
In the above execution contexts, if step4-step8 happens between step1 and
step2 a null pointer dereference is observed -
[ 29.483302] Unable to handle kernel NULL pointer dereference
at virtual address 00000488
[ 29.490366] pgd = c0004000
[ 29.493054] [00000488] *pgd=00000000
[ 29.518937] PC is at do_raw_spin_lock+0x8/0x13c
[ 29.523445] LR is at _raw_spin_lock_irqsave+0x20/0x28
[ 30.108789] [<c0339cd4>] (do_raw_spin_lock+0x8/0x13c) from
[ 30.118418] [<c095d178>] (_raw_spin_lock_irqsave+0x20/0x28) from
[ 30.127445] [<c0142ef4>] (__wake_up+0x20/0x50) from
[ 30.136124] [<c0663f70>] (mmc_request_done+0x30c/0x368) from
[ 30.145932] [<c067bd98>] (sdhci_tasklet_finish+0x130/0x13c) from
Change-Id: I9a21431b5fd9bb9bbcb5c18a9895096fe845e64b
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
[merez@codeaurora.org: fixed conflicts due to missing stop transmission]
Signed-off-by: Maya Erez <merez@codeaurora.org>
[subhashj@codeaurora.org: fixed trivial merge conflicts]
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Fix race condition between mmcqd thread and the mmc_queue_suspend
updating a shared variable mq->flags, which can lead to potential
null pointer dereference as following-
Unable to handle kernel NULL pointer dereference at
virtual address 00000020
pgd = c0004000
[00000020] *pgd=00000000
mmcqd/0: 186] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
CPU: 0 Tainted: G W (3.4.0-1251694-eng #1)
PC is at mmc_blk_err_check+0x20c/0x3b8
LR is at mmc_start_req+0x198/0x718
cpu0 | cpu1
x |= 1 | x |= 2
final value of x can be x = 1 or x = 2
Change-Id: Ie0fff6d6dba5aebb3584cba9fb98de24515c4cd8
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
[merez@codeaurora.org: fix conflicts due to missing stop transmission
and changes in new request implementation in 3.14]
Signed-off-by: Maya Erez <merez@codeaurora.org>
[venkatg@codeaurora.org: Fix conflicts due to changes in 3.14 kernel]
Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
[subhashj@codeaurora.org: fixed trivial merge conflicts]
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
If the mmc_hw_reset() fails, then host->card might be NULL in some
cases. Hence, check for reset errors and report it to the caller so
that the current request can be aborted and also check for host->card
before accessing it so as to prevent NULL pointer dereference issue.
Change-Id: Iba0f0be314474e607a40383bc0b28eef66a31d63
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
[subhashj@codeaurora.org: fixed trivial merge conflicts]
Signed-off-by: Subhash Jadavani <subhashj@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>
[merez@codeaurora.org: fix conflicts as mmc_update_clk_scaling is missing on 3.14]
Signed-off-by: Maya Erez <merez@codeaurora.org>
After removing the SD/MMC 'card' from the driver model we
are cancelling the pending clock scaling work which accesses
card->dev. This could cause NULL pointer issue as the card
is already removed.
CRs-Fixed: 640344
Change-Id: I8c5ee817e3f116dedf0bf4fb51eb6b70d52467b7
Signed-off-by: Pratibhasagar V <pratibha@codeaurora.org>
Get the various drive types other than the default supported
by the card.
Change-Id: I122971e4fb4a3ab98f0078ceafca3380e9c0e2d1
Signed-off-by: Krishna Konda <kkonda@codeaurora.org>
[subhashj@codeaurora.org: fixed merge conflicts and fixed compilation
errors]
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
mmc block data can be NULL. Hence, check for NULL before
dereferencing md.
CRs-Fixed: 562259
Change-Id: I0182c216ec73347cdd2ea464f593839fffd242a9
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
[merez@codeaurora.org: fix conflicts due to removal of BKOPS statistics]
Signed-off-by: Maya Erez <merez@codeaurora.org>
[subhashj@codeaurora.org: fixed trivial merge conflicts]
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
In low memory conditions at runtime, allocation of max_segs may
fail. Retry with a scaled down max_segs until allocation succeeds.
CRs-fixed: 583267
Change-Id: I072724afa44854dacc58654e6329531c1bb11120
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
In case of any error within mmc_blk_alloc_req(), the bitmaps
that keep track of devices are not getting cleared. This may
result in failure to detect a card in case it reaches maximum
devices limitation. Fix it by clearing those bitmaps appropriately.
CRs-fixed: 563264
Change-Id: I0e23c45856355565534146f5fabb957fd4b1d007
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Added checks to check if card is NULL before accessing it.
CRs-Fixed: 548450
Change-Id: Idc005b8420a78b3566164102fbeaa243a8e73c7c
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
[subhashj@codeaurora.org: fixed trivial merge conflicts]
Signed-off-by: Subhash Jadavani <subhashj@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>
[venkatg@codeaurora.org: fix mmc_select_hs args and MAX_DTRs
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>
In the MMC card debug_fs the read and write handlers use the strlcat
and sscanf, without checking the pointer given.
Since the pointer is not checked it is possible to write
everywhere (ring 0 or 3).
In order to fix it, an access_ok function is being used to verify
the buffer's pointer supplied by user is valid.
CRs-fixed: 545716
Change-Id: Ia710b6af5a95974fc930ca902e8ff18afa4e17ba
Signed-off-by: Raviv Shvili <rshvili@codeaurora.org>
[merez@codeaurora.org: Fixed conflicts due to missing BKOPS statistics]
Signed-off-by: Maya Erez <merez@codeaurora.org>
The SD cards functionality on QRD devices are failing
with CRC errors when used with higher clock / bus modes.
So reduce the clock speed for SD card slot.
CRs-Fixed: 491789
Change-Id: I24b8bfe44cee4367c22846747f439365d8795d2e
Signed-off-by: Pratibhasagar V <pratibha@codeaurora.org>
[merez@codeaurora.org: msm8226-qrd-dtsi is not included in 3.14]
This patch whitelists the AR6004 card for clock-gating.
The controller supports asynchronous interrupt functionality
which enables to receive interrupts from the card when clocks
are off. Hence, clocks can be turned off when idle.
This patch whitelists the card, to let the clock-gating
framework gate the clock during idle time.
Change-Id: I651f86e42595cc82f99093c06ee220a1d0ec95a9
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
During voltage sequence (for UHS SD/SDIO cards), host first sends the
voltage switch command (CMD11) to card and then host must stop the clock
at least for 5ms but currently there is a possibility (if clkgate_delay
is 0) that clock may be gated off immediately after the CMD11 response
from card and then get turned on before 5ms itself. This patch ensures
that clock is gated off at least for 5ms after receiving the card
response for voltage switch command.
Change-Id: I131b3d154adab29bef367c8ce31c2f2edd159fd2
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
[subhashj@codeaurora.org: fixed merge conflicts]
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
For several MoviNAND eMMC parts, there are known issues with secure
erase and secure trim. For these specific MoviNAND devices, we skip
these operations.
Specifically, there is a bug in the eMMC firmware that causes
unrecoverable corruption when the MMC is erased with MMC_CAP_ERASE
enabled.
References:
http://forum.xda-developers.com/showthread.php?t=1644364https://plus.google.com/111398485184813224730/posts/21pTYfTsCkB#111398485184813224730/posts/21pTYfTsCkB
Change-Id: I9946828b9c9063da312f95483fcc47e26585489a
Signed-off-by: Ian Chen <ian.cy.chen@samsung.com>
Reviewed-by: Namjae Jeon <linkinjeon@gmail.com>
Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Cc: stable <stable@vger.kernel.org> [3.0+]
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Pratibhasagar V <pratibha@codeaurora.org>
Patch-mainline: v3.6
Git-commit: 3550ccdb9d
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
This patch initializes wakeup source if the detected card
is a sdio card and enables the wakeup capability.
Platform drivers would have to invoke:
* pm_wakeup_event on this card device to signal a wakeup
* corresponding pm_relax have to be invoked
Change-Id: Ic8d5c98073e8ed3f676eb42fc0ce1f13a11cb40f
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
[merez@codeaurora.org: fix conflicts due to different PM in 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>
During suspend, eMMC VCC can be turned off. So instead of sending
a power off notification, send a sleep command. According to the
eMMC 4.5 specification, this is the only time where its clearly
mentioned that the VCC regulator can be turned OFF.
This has been clarified in eMMC 5.0 specification and this applies
even if PON with sleep is not sent to the card.
Change-Id: I6c424bed3158132af7f9c2a2a701af7369fd5ec7
Signed-off-by: Krishna Konda <kkonda@codeaurora.org>
[merez@codeaurora.org: fix conflicts due to changes in 3.14]
Signed-off-by: Maya Erez <merez@codeaurora.org>
During the copy the last character was getting truncated.
Update the buffer copy to include all the characters.
CRs-Fixed: 499579
Change-Id: I8e1df1d1f2294e85068aebcc876bef701e088b07
Signed-off-by: Pratibhasagar V <pratibha@codeaurora.org>
mmc_queue_suspend() function returns the -EBUSY error if the MMC request
queue is not empty as this function was getting called from the system
suspend path which enforces time limit on the completion of the driver
suspend callback.
But recently the driver shutdown routine also started using
mmc_queue_suspend() function but in shutdown case, we would really want
to wait for the MMC request queue to be empty.
To fix above issue, this change have added new argument named "wait" to
mmc_queue_suspend() function which would tell whether it needs to wait
for the MMC request queue to be empty or not. Driver shutdown callback
will tell the mmc_queue_suspend() to wait but suspend callback won't.
CRs-Fixed: 503227
Change-Id: I86f32d68ec4c4799648785681c5776f090ea6e36
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Verify drv and card pointers before calling for driver shutdown.
Change-Id: I855e32f988ec1af475df6ed91f04618525e1a59f
Signed-off-by: Eugene Yasman <eyasman@codeaurora.org>
[merez@codeaurora.org: fix conflicts due to changes in 3.14]
Signed-off-by: Maya Erez <merez@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>
[merez@codeaurora.org: fix conflicts as some of the code was already included]
Signed-off-by: Maya Erez <merez@codeaurora.org>
[venkatg@codeaurora.org: Remove PM related code]
Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
[subhashj@codeaurora.org: fixed trivial merge conflicts]
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>
[merez@codeaurora.org: fix CAPS2 index]
Signed-off-by: Maya Erez <merez@codeaurora.org>
[subhashj@codeaurora.org: fixed trivial merge conflicts]
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>
[merez:codeaurora@org: fix conflicts due to removal of stop transmission]
Signed-off-by: Maya Erez <merez@codeaurora.org>
[subhashj@codeaurora.org: fixed trivial merge conflicts]
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
In the current implementation packing is enabled according to a statically
defined trigger. This patch updates the packing control mechanism to use a
dynamically defined trigger.
The trigger's value is calculated by the relation
between the number of potential packed write requests and the mean
value of all previous potential values:
If the current potential is greater than the mean potential then
the heuristic is that the following workload will contain many write
requests, therefore we lower the packed trigger. In the opposite case
we want to increase the trigger in order to get less packing events.
In case we get an urgent request we 'punish' the packing control by
increasing the trigger.
Change-Id: I775e1582ad32a8f798e8b2bd2b3178aef357e747
Signed-off-by: Lee Susman <lsusman@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>
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>
