In mmc_block_test, the debug_fs based read function handlers write to an
arbitrary buffer which is given by any user. We add an access_ok check
to verify that the address pointed by *buffer is not in kernel space.
Only if the buffer is valid, do we continue the read handler.
Backport reference:
* Ignore changes from following upstream functions:
- bkops_test_read
- long_sequential_read_test_read,
- long_sequential_write_test_read
- new_req_notification_test_read
Change-Id: I1413f71be13509a3b4e56b919cfbcbd9fcc9d2bd
Signed-off-by: Lee Susman <lsusman@codeaurora.org>
Signed-off-by: Maya Erez <merez@codeaurora.org>
Signed-off-by: Adrian DC <radian.dc@gmail.com>
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.
Bug: 28769136
CRs-fixed: 545716
Change-Id: Ia710b6af5a95974fc930ca902e8ff18afa4e17ba
Signed-off-by: Raviv Shvili <rshvili@codeaurora.org>
sending power off notify to eMMC before power off.
trigger sw reset before actual HW reset.
Change-Id: I4e3df098b084cc5f39cfd1c52718ed0833d8ba24
Signed-off-by: hsuan-chih_chen <hsuan-chih_chen@asus.com>
bug: 17968808 Kernel change for new eMMC v5.0 parts for FLO/DEB
Change-Id: Ia18152457fe3ff70401b199c267fa37374b9d544
Signed-off-by: hsuan-chih_chen <hsuan-chih_chen@asus.com>
Current MMC driver doesn't handle generic error (bit19 of device
status) in write sequence. As a result, write data gets lost when
generic error occurs. For example, a generic error when updating a
filesystem management information causes a loss of write data and
corrupts the filesystem. In the worst case, the system will never
boot.
This patch includes the following functionality:
1. To enable error checking for the response of CMD12 and CMD13
in write command sequence
2. To retry write sequence when a generic error occurs
Messages are added for v2 to show what occurs.
cherry-picked from
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/mmc?id=c8760069627ad3b0dbbea170f0c4c58b16e18d3d
Signed-off-by: KOBAYASHI Yoshitake <yoshitake.kobayashi@toshiba.co.jp>
Signed-off-by: Chris Ball <cjb@laptop.org>
Conflicts:
drivers/mmc/card/block.c
Change-Id: Ieeb9fb142ff1be7904e322354d9647cfa239e862
Signed-off-by: Devin Kim <dojip.kim@lge.com>
when recieving PON, some eMMC tend to program spare block with
init data for next power cycle. If eMMC recieved PON frequently
but not actually powered off. blocks being programed became
really dirty and caused performance decline.
Sending cmd5 frequently could also be stress to NAND block for
some eMMC. Hence bypass cmd5 to extend eMMC life cycle.
Change-Id: I2cee3a048da8d4e814befd0192675d3f58cd3f90
Signed-off-by: hsuan-chih_chen <hsuan-chih_chen@asus.com>
SDR104 (supported by SD3.0 spec compliant SD cards) bus speed mode
requires DLL (Delay Locked Loop for sampling clock generation) HW
block to be tuned if clock rate is >100MHz. To help the sampling clock
tuning SD3.0 specification has added CMD19.
During card initialization, driver uses these tuning commands to search
for optimal sampling point and then programs the DLL HW with this optimal
sampling point.
In addition, our SDCC controller's DLL HW has a mechansim of data
tracking (CDR) which can be enabled during read transaction so the host
will not lose the sampling point as a result of voltage and, especially,
temperature variations. Tuning pattern commands (CMD19) can be sent
automatically by HW (by using AUTO_CMD19 bit) before any RX transaction
for helping the CDR to track after the correct sampling point.
Although sending CMD19 automatically before every read commands is
overhead and reduces read performance by ~1 MB/s. SD spec does
not mandate to send these commands before every read operations.
This change keeps AUTO_CMD19 disabled by default but provides sysfs
attribute to enable or disable AUTO_CMD19 as per need.
Change-Id: I9ef99a8dde9b9733ea99639cdab2b6714ac50d76
Signed-off-by: Subhash Jadavani <subhashj@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.
(cherry picked from commit 202befb5a5a344f88a0b4fd1ed07b9a2c7ce4e3d)
(cherry picked from commit 91e1e32573321986b141f153ffdb5bcc8affe95b)
Change-Id: I06638dc19aa7703d0571d9699b24ce9977b1bcb8
Signed-off-by: Lee Susman <lsusman@codeaurora.org>
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
(cherry picked from commit 273c29cec62e3f771bc726cf226c66234ceb80cb)
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.
(cherry picked from commit 285ee17e20580759ef349b43e48565cfad8adb10)
Change-Id: I384d74dc6eece67358a51fb0add5d988aee44d5d
Signed-off-by: Maya Erez <merez@codeaurora.org>
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
(cherry picked from commit 659fc08c2d5f7b46c3543feb618f4708dc78b77b)
mmc_stop_bkops calls cancel_delayed_work_sync while the host is taken.
This can cause a deadlock since the delayed work is blocked on claiming
the host. In order to prevent that, mmc_start_bkops will not
be blocked waiting on mmc_claim_host and if the host is already taken
BKOPS will not be performed.
CRs-Fixed: 446090
Change-Id: I5cda5489e254764b3231b8a12da9e3c241c969c3
Signed-off-by: Maya Erez <merez@codeaurora.org>
(cherry picked from commit 8571386b83bea1cbadd81c75bf0614da30b6b7c0)
If there is a race condition between the delayed BKOPS work and
the runtime suspend, and the suspend occurs before the delayed work,
the delayed work should be canceled.
Since mmc_claim_host can fail in case the host is suspended, we should
check if the delayed work is canceled before trying to claim the host.
CRs-Fixed: 443236
Change-Id: I9df506de4da6f9277a89ed608724f5b6e8585bfd
Signed-off-by: Maya Erez <merez@codeaurora.org>
(cherry picked from commit 5a3d216c005725baad96b6858dbcd370056e470c)
In order to keep card endurance, it is best not to check the need for
BKOPS every time the MMC is idle.
However, the decision when to check the card need for BKOPS according
to number of changed sectors doesn't fit all cards sizes. Therefore,
the check for BKOPS need is based on percentages of changed sectors
of the card size.
In order to assure that BKOPS will be triggered again in case it was
interrupted, the accumulated number of changed sectors is cleared only
in case BKOPS was completed without interruption.
Change-Id: I598f64b652a524a431b87d103fd5890b808f11b1
Signed-off-by: Maya Erez <merez@codeaurora.org>
(cherry picked from commit e1eae988976536834759a45cf7f62e1cb2b82838)
BKOPS operations can take long time and cause bad user experience and
failure of time critical operations as EFS sync.
In order to prevent the above failures all the levels will be handled only
in idle time BKOPS handling and will allow interrupting the BKOPS when
needed.
In case the card raised an exception with a need for BKOPS, a flag will
be set to indicate MMC to start the BKOPS activity when it becomes idle.
Fixed-CRs: 432027
Change-Id: I5f7b43569c0242f0fea83355f76f286b1ad037bc
Signed-off-by: Maya Erez <merez@codeaurora.org>
(cherry picked from commit 5f8ac3b955e44def61c2238192000ffe5f126714)
The timeout for the BKOPS polling is increased in order to allow the
card to complete the BKOPS before going to suspend.
In case we exit due to timeout we need to stop the BKOPS activity
performed by the card.
Change-Id: I39686de0c06a57242f11c8b1c9ae50b33417c088
Signed-off-by: Maya Erez <merez@codeaurora.org>
(cherry picked from commit ea1385e6d7542d4e3ad510de94ead00bece7823e)
mmc_cache_ctrl was called in runtime suspend before MMC interrupted
BKOPS in case it is still running on the card. This caused the cache
disable to timeout.
Therefore, mmc_cache_ctrl has to move to mmc_suspend where we are sure
that the card can go into suspend and there is no pending activity.
CRs-Fixed: 436805
Change-Id: I76281a766f48ccacc24685a64067df4e60cfe1d8
Signed-off-by: Maya Erez <merez@codeaurora.org>
(cherry picked from commit 67a51386fd99be62e5e68f4bc76ee00c19099cd6)
In order to allow the card to perform BKOPS as early as possible without
causing degradation to a flow of requests, we reduce the time of the
BKOPS delayed work to 200ms.
Based on experience, 200ms will allow requests to be performed without
a delay of checking the BKOPS.
This patch also allows the host controller to set any other time if
required.
Change-Id: I1e56bfd0c9471abf4da50befe6d14fe0199129e7
Signed-off-by: Maya Erez <merez@codeaurora.org>
(cherry picked from commit 70b00220e7564b00e3b0747260fe2c2dbe62f45d)
Sanitize command should never be issued with timeout argument of 0,
cause then it invokes timeout.
Moreover, sanitize command should not be called from routines that
does erase/trim/secure-discard commands, but only from a routine that
issues the sanitize spesifically.(mmc_blk_issue_sanitize_rq)
Change-Id: Ia3e3737f4bad149edc2248b8a30d74a9bd812be1
Signed-off-by: Yaniv Gardi <ygardi@codeaurora.org>
(cherry picked from commit 9a87427db940047907aee0dc86965645656f1ca9)
Signed-off-by: Neha Pandey <nehap@codeaurora.org>
For APQ8064 V2 (SDCC version = 0x06000018) doing a soft
reset on errors doesn't reset the state machine that
handles side-band signalling with SPS-BAM fully and can
lead to controller hang for the data transfers after
the reset.
Since there is no register interface to soft reset such
state machine inside the controller, we do hard reset of
the controller in case of errors. SDCC hard reset is
defined as assert and de-assert of asynchronous clock
reset line of the controller.
CRs-Fixed: 451632
Change-Id: I366856e7508a3843688c8acead8a701e7b06fc19
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
We have seen instances where card is surprisingly taking lot of time
to complete their bkops operations. And if we let the card take long
time to complete the BKOPs then it would affect the user experience
if user tries to launch some application (or any other user operation
resulting in read from the card) while card is busy doing BKOPs.
User experience is most important aspect so we are reducing the maximum
BKOPs timeout to max 30 secs and if card doesn't complete the BKOPs in
the timeout specified above, we will send the HPI command to interrupt
the on going BKOPs.
If reduce the timeout to 30 secs then we may see the request timeout
errors during BKOPs so let's silence them out.
Change-Id: I31b11f60d1fae098770aa5797742eaf623b09ac9
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
(cherry picked from commit 926a9cb47ebfa40428b49f110135fde9e82f9cbe)
Currently we have 4 mins timeout for the blocking bkops to be completed
but we have seen instances where card is surprisingly taking even more
time to complete their bkops operations. So if we let the card take
more than 4 mins then it would affect the user experience if user tries
to launch some application (or any other user operation resulting in
read from the card) while card is busy doing BKOPs.
User experience is most important aspect so we are reducing the maximum
BKOPs timeout to max 30 secs and if card doesn't complete the BKOPs in
the timeout specified above, we will send the HPI command to interrupt
the on going BKOPs.
Change-Id: I14355fb79979058f388cd726091752797c316503
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
(cherry picked from commit 188b2a8723b4728c7c0c4c445e1aefe6e42895c9)
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>
(cherry picked from commit 1b22222ec61924de9b8ac51f08de113548946eb5)
Currently SDCC driver is waiting for the PROG_DONE interrupt after
sending out the CMD13 to card even if command flags doesn't indicate
so. This may cause the issue in when we try to HPI (High Priority
Interrupt) the ongoing BKOPs (Background Operations). Hence this
change removes the busy wait (PROG_DONE) for CMD13.
Change-Id: I8fb6ab4908bf1c4c5a939413d27eec29cde22f68
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
(cherry picked from commit 56fd45187495f27a7f9c3ebe947c1ffc9851fffd)
Reset SDCC controller if the check for TX/RX ACTIVE bit fails while
carrying out DPSM reset after the end of current transaction
instead of taking the entire system down by doing BUG().
CRs-Fixed: 423356
Change-Id: I9e2e945eb9a31d12e0a435df29a8215ae634724b
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
(cherry picked from commit 0a29588be6d3d6bd9122191e7e850c687bb1b166)
Signed-off-by: Maya Erez <merez@codeaurora.org>
Resetting SDCC-BAM after reset of SDCC-DML causes
interface disconnect between SDCC-BAM and SDCC-DML
and lead to hang when SDCC driver initiates data
transfer in BAM mode. Modify the SDCC reset sequence
to reset SDCC-DML after reset of SDCC-BAM.
CRs-Fixed: 423399
Change-Id: Ia31d40e30cbf95befba3b1133a525a81903789f2
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
(cherry picked from commit b745eeb229a476d81ee4177adfe168d3a35bda47)
Reset SDCC controller if the check for TX/RX ACTIVE bit fails while
carrying out DPSM reset after the end of current transaction
instead of taking the entire system down by doing BUG().
CRs-Fixed: 423356
Change-Id: I9e2e945eb9a31d12e0a435df29a8215ae634724b
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
If SDIO keep power flag (MMC_PM_KEEP_POWER) is not set, card would
be reinitialized during resume but as we are not resetting
(CMD52 reset) the SDIO card during this reinitialization, card may
fail to respond back to subsequent commands (CMD5 etc...).
This change resets the card before the reinitialization of card
during resume.
(cherry picked from commit 2679307563a616af7ab189706604a245c6a3be92)
CRs-Fixed: 424805
Change-Id: I1ccd93e9221de631a407064219793e7378ac8f31
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Neha Pandey <nehap@codeaurora.org>
Notifying the device of the hosts intention to power it off, gives the
device the ability to better prepare itself.
(cherry picked from commit f495d1b0d837af16a9e9881dbbcd7908abf88b33)
Change-Id: I43a6c576ea48508d60723f1002fc0fb26e9eafe4
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
(cherry picked from commit 916072e4cb9373c054bc5a91ff289ac769958993)
This patch fixes up the broken suspend sequence for eMMC with sleep
support. Additionally it reworks the eMMC4.5 Power Off Notification
feature so it fits together with the existing sleep feature.
The CMD0 based re-initialization of the eMMC at resume is re-introduced
to maintain compatiblity for devices using sleep.
A host shall use MMC_CAP2_POWEROFF_NOTIFY to enable the Power Off
Notification feature. We might be able to remove this cap later on,
if we think that Power Off Notification always is preferred over
sleep, even if the host is not able to cut the eMMC VCCQ power.
[merez@codeaurora.org: resolved various merge conflicts.
Fix in mmc_resume already exists]
(cherry picked from commit cec02a451276a70cdeb0576ec89d6b5b76e4e18b)
Change-Id: I4f29c213d745dcb1ec50b34b535657328042b4b2
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Saugata Das <saugata.das@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
Signed-off-by: Maya Erez <merez@codeaurora.org>
(cherry picked from commit 91cf2698afab3f0707f739a02eb639205798f1dc)
When a failure occurs while creating a device attribute,
we need to remove previously created attributes prior to deleting
the disk.
(cherry picked from commit 8d006d3f139c46beaeee138bda9d0807185661a9)
Change-Id: Ic5ebba9c06f3811534f5b5e8c0399809e5dc9f23
Signed-off-by: Maya Erez <merez@codeaurora.org>
(cherry picked from commit 7256cdc299a4d42c1d316afbac98d320154ce6da)
The version of PON support accepted by the linux community is
slightly different from the one that was merged. This revert is needed
in order to upload the latest version from the linux community.
This reverts commit 76058d7388c6edde07fd6289ce082dc1a1813b26.
(cherry picked from commit 8b458cf768db937d3a2274e216819a1a217e97f8)
Change-Id: I0cb611698b25de600dbaa54678edae661456e485
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
(cherry picked from commit 6e3e74d3ba5c825108b0a63018376b12e61592f9)
In the current soft reset sequence performed as part of
CMD/DATA error recovery we do the following:
1) Write 1 to DML_SW_RESET
2) Reset CPSM/DPSM by clearing MCI_CMD and MCI_DATA_CTL
or by writing to MCI_SW_RST_CONFIG.
3) Re-init DML
4) Reconfigure both consumer and producer BAM pipes.
The BAM pipe reset does not reset the sideband signals, since
only SDCC side is reset SDCC - BAM communication will go out
of sync and cause DML to be stuck without transferring data.
Hence reset BAM core every time SDCC is reset (which is on
error recovery).
Fix error handling for sps pipe or device reset.
(cherry picked from commit 3ca90f02963ddbbdb300eb55c49aca18091c3f49)
Change-Id: I82bd6c5f3db6ac71da912cef935dfd179b099ed4
Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
Signed-off-by: Krishna Konda <kkonda@codeaurora.org>
(cherry picked from commit 9b2f00f099f4f17025a9834eb38fc67254164608)
Signed-off-by: Maya Erez <merez@codeaurora.org>
Due to the revert and cherry-pick of latest version from
the community, we had some errors in the final code of packed
commands. This patch fixes this mismatch
(cherry picked from commit 47b37929ebffeb2672a4bcbea38ae4e79d7d4e26)
Change-Id: Iff688ca3aaa893d9bd7f876a8d2d7c3d4d750a8a
Signed-off-by: Maya Erez <merez@codeaurora.org>
(cherry picked from commit e05b4d698362433009b4cdef75952c72de0f38cf)
mmc_cache_ctrl is called during the suspend path and it used
mmc_claim_host which is a blocking call and the device never
really suspends as it waits for the host to be available.
This also leads to race conditions during runtime power
management operation, for example, runtime suspend can start
while the device is being runtime resumed. So in order to
prevent this, mmc_try_claim_host should be used during
suspend path, which is non-blocking.
(cherry picked from commit 4d6b6238793e836189db5ec00c8c7890b11c9997)
Change-Id: Ib63a00b1c31159eefa4e5c4fa646c4cf77905f05
Signed-off-by: Krishna Konda <kkonda@codeaurora.org>
(cherry picked from commit 2638637f5b68a339cbac6e5841218761d7926b8c)
This attribute is used to determine whether the status bit that
indicates the need for BKOPS should be checked. The value is stored in
this attribute represents the minimum number of sectors that needs to
be changed in the device (written or discarded) in order to require
the status-bit of BKOPS to be checked
(cherry picked from commit e6c6b4b14ac2f10aa34cf42b6f558152e438bb37)
Change-Id: I3b05a0826fc9397a13d6b03ee028293f877f8d66
Signed-off-by: Yaniv Gardi <ygardi@codeaurora.org>
(cherry picked from commit 15ecbe1c5f6b2f2af5974f23cd494fce0c5bf81a)
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
(cherry picked from commit 09b010d749e40e86b42e62406f8886956e03f3bd)
Change-Id: I563a17b8dc313e65c20ed24d542d29ab7b432741
Signed-off-by: Lee Susman <lsusman@codeaurora.org>
Signed-off-by: Maya Erez <merez@codeaurora.org>
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
(cherry picked from commit 1dc976ea347887060c162a80b3180a0981b5d1bd)
Devices have various maintenance operations need to perform internally.
In order to reduce latencies during time critical operations like read
and write, it is better to execute maintenance operations in other
times - when the host is not being serviced. Such operations are called
Background operations (BKOPS).
The device notifies the status of the BKOPS need by updating BKOPS_STATUS
(EXT_CSD byte [246]).
According to the standard a host that supports BKOPS shall check the
status periodically and start background operations as needed, so that
the device has enough time for its maintenance operations.
This patch adds support for this periodic check of the BKOPS status.
Since foreground operations are of higher priority than background
operations the host will check the need for BKOPS when it is idle,
and in case of an incoming request the BKOPS operation will be
interrupted.
When the mmcqd thread is idle, a delayed work is created to check the
need for BKOPS. The time to start the delayed work is calculated based
on the host controller suspend timeout, in case it was set. If not, a
default time is used.
If BKOPS are required in level 1, which is non-blocking, there will be
polling of the card status to wait for the BKOPS completion and prevent
suspend that will interrupt the BKOPS.
If the card raised an exception, the need for urgent BKOPS (level 2/3)
will be checked immediately and if needed, the BKOPS will be performed
without waiting for the next idle time.
(cherry picked from commit 5f360698caa2894f7cc854199ffba285241d152e)
Change-Id: I6605ce396188807bed93f437224f2243b178523f
Signed-off-by: Maya Erez <merez@codeaurora.org>
(cherry picked from commit 833940e728c5903f0263c20e349bbead7a79e535)
This patch adds "large sector size" as a reason for stop packing
to the packing statistics mechanism
(cherry picked from commit 1718ef21fb791a2ea25bd3fbf236913de64ca85f)
Change-Id: I595f7839fa9156d5ed26040943c1d5e3011c2a60
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
(cherry picked from commit bd8d562c886ffe3a07b9a56a446eb5b5b7db23ed)
The write packing statistics are used for the packed commands unit tests
in order to determine test success or failure
(cherry picked from commit 464fbe1af0248b7e85044ccebf4d4d96dd8fdeaa)
Change-Id: If5465118e0ea1b4c78b73a43b664d5b6bc9cae31
Signed-off-by: Maya Erez <merez@codeaurora.org>
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
(cherry picked from commit db2e25650ab5fb62143ff39fcaea083176403fd1)
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.
(cherry picked from commit 0cc76400d65f0d7b3f2f8f1ece3c8061652a35d7)
Change-Id: I51a44d2673e40e4e404317ddb632a9fb204e9a06
Signed-off-by: Maya Erez <merez@codeaurora.org>
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
(cherry picked from commit fd402c28f1571b64f4d695d191778e9dd595806a)
This patch supports packed write command of eMMC4.5 device.
Several writes can be grouped in packed command and all data
of the individual commands can be sent in a single transfer
on the bus.
[tlinder@codeaurora.org: Difference in definition:
R1_EXP_EVENT -- > R1_EXCEPTION_EVENT]
(cherry picked from commit 53f8f574c6c68687098cd064af8224da44de2484)
Change-Id: I26ee7c0b957a3aec5e4ffc6d6df806ea38435784
Signed-off-by: Seungwon Jeon <tgih.jun@samsung.com>
Reviewed-by: Maya Erez <merez@codeaurora.org>
Reviewed-by: Namjae Jeon <linkinjeon@gmail.com>
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
(cherry picked from commit 6d24bc3b6e86412cbfbc37377bbbf196cbdebce9)
This patch adds packed command feature of eMMC4.5.
The maximum number for packing read(or write) is offered
and exception event relevant to packed command which is
used for error handling is enabled. If host wants to use
this feature, MMC_CAP2_PACKED_CMD should be set.
(cherry picked from commit c70e9669bffa2f2ffe4d8f9768980e1cd08df4b2)
Change-Id: If3af1299c7dbdc9f66b13ec5b99038225d5b17f0
Signed-off-by: Seungwon Jeon <tgih.jun@samsung.com>
Reviewed-by: Maya Erez <merez@codeaurora.org>
Reviewed-by: Subhash Jadavani <subhashj@codeaurora.org>
Reviewed-by: Namjae Jeon <linkinjeon@gmail.com>
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
(cherry picked from commit 458c9b55dd3e06d6cd36158bd96a6d4935ed4fea)
The write packing allows sending several requests in a single command
to the card and increases the eMMC performance in sequential write
operations.
(cherry picked from commit 34a444f2041763d617391be44f4a9ac1b7d6eab7)
Change-Id: I45978c8130d3898b21e36309696647c380521a87
Signed-off-by: Maya Erez <merez@codeaurora.org>
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
(cherry picked from commit 94a78f62307a53e9051e6f3970e1a937361078ba)
Signed-off-by: Maya Erez <merez@codeaurora.org>
The version of packing support excepted by the linux community is
slightly different from the one that was merged. This revert is needed
in order to upload the latest version from the linux community.
This patch reverts the following commits:
1.mmc: card: Add eMMC4.5 write packed commands unit-tests
2.mmc: card: Fix packing control enabling algorithm
3.mmc: block: Add MMC write packing statistics
4.mmc: msm_sdcc: enable the write packing control
5.mmc: msm_sdcc: Enable write packing capability
6.mmc: block: Add write packing control
7.mmc: core: Support packed write command for eMMC4.5 device
8.mmc: core: Add packed command feature of eMMC4.5
(cherry picked from commit f94cf3da103b344b13fa4d6665fd21dad1b95ead)
Change-Id: I2efc6dc8d8f6d5cc7e9efa99ec74914ffff96fcd
commit: 9b54d88c6a11ebfe069b7fdebcb521da21754c3f
commit: e2ecb58a6c5011549aac3e86fb1c13e7b7c65104
commit: e544d700e2dac1584a8172c4dc347d81ede203bd
commit: 8afe8d2a98a1bbf3804162ff5c95a56226935f5a
commit: 25e2261a556c4393f79d58bce814bb3df34b9549
commit: 63c61d6d8b8f37c71b4162b3affffdf72ac06811
commit: 968c774ea6466fa7adbf2eac333220132acda306
commit: 516994eee39282b8648b509e449ff83b49833209.
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
(cherry picked from commit 31fe84d6edae65f9df5663538e528697897be86e)
Signed-off-by: Maya Erez <merez@codeaurora.org>
Set MMC_CAP2_INIT_BKOPS. This will set the BKOPS_EN bit in the
ext_csd register. The BKOPS_EN bit is one time programmable.
(cherry picked from commit b7f382b25fbd363c43af2332b4ff490e13aab6e4)
Change-Id: Ie913561b2b82ff28366ffe564ffcafe8fc19a96a
Signed-off-by: Maya Erez <merez@codeaurora.org>
(cherry picked from commit 2d29e0d34e3304d976291d3ab29c7c893c12d740)
If the card and the host support BKOPS, and BKOPS is not enabled
yet, set the BKOPS_EN bit to enable BKOPS.
This bit is one time programmable.
(cherry picked from commit e966c1ca32d118b26ca6e26267f0c13c9c0e0052)
Change-Id: I2b97898857bed676021fe56a6f6e49762cf609fa
Signed-off-by: Maya Erez <merez@codeaurora.org>
(cherry picked from commit 5ebe331e59e9c30bffead8e3030e3581ee699895)
