Clock scaling logic relies on active data request tracking variable to
start/stop counting the bus busy period and we are also crashing the
system if this tracking variable shows that new request tag is already
in use. Set/Clear logic of this tracking variable is done only if
clock scaling is enabled but consider following sequence of events:
1. Clock scaling is enabled
2. New request comes in which sets the appropriate tag in tracking
variable.
3. Clock scaling gets disabled (for some reason) before the request
completion.
4. Request gets completed but it doesn't clear the corresponding tag
in tracking variable.
5. Clock scaling gets re-enabled.
6. New request is issued with the same tag which was never cleared from
tracking variable hence we would hit the BUG_ON and system will crash.
Fix this issue by doing set/clear of tracking variable irrespective of
clock scaling state.
Change-Id: Idffd1247ec1275e782e1ad9eb91faa81bc3ba347
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Block layer queue on suspend flow gives up if there are active requests,
while shutdown flow stops issuing thread and waits for completion of
outstanding requests and never give up.
This change propagates additional parameter to differentiate between
suspend and shutdown flows
Change-Id: I35a036c1a5585e3088301c07ade7d09ebd2cfc1b
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
[subhashj@codeaurora.org: fixed merge conflicts]
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Currently getting status/ext_csd using debugfs or IOCTL
calls in cmdq mode is not working.
Fix it by halting the cmdq engine and making sure that
card queue is empty before issuing these cmds.
Change-Id: Idb89def9ff5c2fee6866759b9a8c652049552933
Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>
[subhashj@codeaurora.org: fixed merge conflicts]
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
As per eMMC specification, the PON (Power Off Notification)
must be sent by host to the card before turning off the power.
This will allow card to prepare itself for the power off and
may even reduce the initialization of eMMC upon next boot-up.
Send long PON during system power off and send short PON during
system reboot to reduce the reboot latency.
Change-Id: If4188b8b80aaa0e6c4e00e1807aa9589d5e7efdb
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Signed-off-by: Krishna Konda <kkonda@codeaurora.org>
[subhashj@codeaurora.org: fixed trivial merge conflicts]
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Add support for handling both manual and auto
bkops when command queuing is running.
Change-Id: Ib967ca3c0420f4e54b3e93c497eb538d7347199a
Signed-off-by: Dov Levenglick <dovl@codeaurora.org>
[subhashj@codeaurora.org: fixed trivial merge conflicts]
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Timeout handler executed on softirq context. cmdq dumpstate() api resumes
platform device and it can't be executed on softirq context. Request
completion callback schedules error handler work in case of timeout error.
This change moves CQE registers dump to the error handler callback.
Change-Id: Iea26ca5240f6031218dcf374cafcf2708df1f125
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
This change adds clock scaling ability to command-queueing
mode, it does so by adding next logic:
* Statistics collection for CMDQ data path
* Empty the queue and Halt it before frequency change
* Scale from data path in case host claiming is not possible
Change-Id: I53a323b55df4d7c27e3ee3426ee4e856e533522c
Signed-off-by: Talel Shenhar <tatias@codeaurora.org>
Add support for manual and auto bkops for
legacy (not command-queue) mode.
Change-Id: I1333e1d4330393e446ba48a9474c83295744c050
Signed-off-by: Dov Levenglick <dovl@codeaurora.org>
[subhashj@codeaurora.org: fixed merge conflicts and compilation
errors]
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Since error handling could race with runtime suspend, increase usage_count
for the card device will prevent this race.
Change-Id: Ie95a3c631f519c7993b0032f0b674871b64e4cb6
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
eMMC cache barrier provides a way to perform delayed
and in-order flushing of cached data. Host can use this
to avoid flushing delays but still maintain the order
between the data requests in cache.
In case the device gets more barrier requests than it
supports, then a barrier request is treated as a normal flush
request in the device.
If the eMMC cache flushing policy is set to 1, then the device
inherently flushes all the cached requests in FIFO order. For such
devices, as per spec, it is redundant to send any barrier requests
to the device. This may add unnecessary overhead to both host and
the device. So make sure to not send barrier requests in such cases.
Change-Id: Ia7af316800a6895942d3cabcd64600d56fab25a6
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
[subhashj@codeaurora.org: fixed trivial merge conflicts]
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Enable clock gating for cmdq by adding respective
API to clk hold/release. CMDQ also uses the same
legacy clock gating API.
Change-Id: I3d4f28cedb24ff2292ab08bdd7470358cf134dd5
Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>
CMDQ is not supported for RPMB partition. Hence, for RPMB requests
the controller is kept in HALT state and then CMDQ is disabled in
the card.
Change-Id: I1242841d5fa063b542e35dcff95694ef5e88737a
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Discard is supported in CMDQ mode only when device queue is empty.
Hence, discard commands should be sent using DCMD slot with
QBR (Queue Barrier) flag set.
Change-Id: I630091cbd94ffcdcec71626257f912c15fd2e21e
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
[subhashj@codeaurora.org: fixed trivial merge conflicts]
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
During the shutdown process,
- Stop the queue
- Flush all the pending requests
- Halt the Controller
- Put the card in legacy mode
Change-Id: I5fe4e998bc04bfd8f50de63f3beae3cb25f1c8ba
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
Individual requests can have timeouts defined. The default
timeout is set to 120 seconds. On a timeout, the block layer
notifies the driver and error can be handled thereafter.
Change-Id: Ifcd690411770ab266c12a01bb0993f92b0f18bc6
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
On error, the CMDQ engine stops processing requests. It is then
halted and error handled.
The error have been categorized as below:
1. Command error
a. time-out
- invalidate all pending tags & requeue
- reset both card & controller
b. crc
- end the error mrq
- tune
- unhalt
2. Data error
a. time-out
- invalidate all pending tags & requeue
- reset both card and controller
b. crc
- end the error mrq
- tune
- unhalt
3. RED error
This is device specific error and is not recoverable.
The card and controller are reset in this case and all
pending tags are invalidated and requeued.
Change-Id: I791d05f6b31d8f9b35a56fe85007b320c14e8b46
Signed-off-by: Asutosh Das <asutoshd@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>
There could be a switch of partition while RPMB access.
RPMB thread would then hand-off the control to mmc-cmdq-thread
in the following state:
- partition set to RPMB in card
- CMDQ mode disabled in card
- Controller in halt state
When the next request is received, the following has to be done
- switch partition to the current partition
- enable CMDQ in card
- unhalt controller
Change-Id: I9eca350572fd88476dfee9642696a223c5cd7ada
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
[subhashj@codeaurora.org: fixed compilation error]
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Adds flush request support to command-queue. This uses DCMD
feature of the controller for sending commands in
command-queue mode. DCMD is a direct command feature that uses
a pre-configured slot for sending commands other than Class 11.
Change-Id: Iebf6b74173dc91b0dc7230d1e87c65983d15148e
Signed-off-by: Asutosh Das <asutoshd@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>
Command queueing is defined in eMMC-5.1. It is designed for
higher performance by ensuring upto 32 requests to be serviced
at a time.
Adds read/write support for CMDQ enabled devices.
Change-Id: I136ddea8e5ca57eb4f85ca6e72c60001a7e24f78
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Konstantin Dorfman <kdorfman@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>
Command Queueing (CQ) feature is introduced to eMMC
standard in revision 5.1. CQ includes new commands
for issuing tasks to the device, for ordering the
execution of previously issued tasks and for
additional task management functions.
The idea is to keep the legacy and CQ code as discrete
as possible. Hence, a separate queue is created for CQ.
The issuing path is non-blocking since several requests
(max. 32) can be queued at a time.
Change-Id: I5b48d1b3ed17585b907ec70ff7c8d583003ec9e1
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
[subhashj@codeaurora.org: fixed trivial merge conflicts & compilation
error]
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
This is needed by ICE (Inline Crypto Engine) driver to get
the ICE configuration data from the request.
Change-Id: Ie69c64f4dc0c31290dec50d905e8b3d436c86d62
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
Switch to using pr_err_ratelimited in order to avoid
flooding the logs in case of error function gets
called repeatedly.
Change-Id: I636dc933915127a43ad4da87a565f8f585e6df90
Signed-off-by: Talel Shenhar <tatias@codeaurora.org>
On kernel-3.14 mmc_claim_host is replaced by mmc_get_card to also
call pm_runtime_get_sync.
mmc_blk_ioctl_rpmb_cmd has asymmetric claim and release as mmc_claim_host
was used to get the lock, but mmc_put_card was used for the release.
To fix this and prevent bad counter of runtime PM, mmc_claim_host
should be replaced with mmc_get_card.
Change-Id: I7c2218623fddfbeed0489aed330c9fe6e8bc5338
Signed-off-by: Maya Erez <merez@codeaurora.org>
In case of a flush request timeout, an error is returned
to the block layer.
The problem with this is that the eMMC card is left in
programming state and while the device is in the
programming state it cannot serve any request.
This commit moves the card out of the programming state,
in case of timeout, by issuing HPI, thereby allowing the
device to continue serving requests.
Some filesystems, such as EXT4, remount the partition as
read-only after receiving an error from the block layer, thus
this change will allow the remounted partition to work as the
card can serve read request thanks to the HPI.
In case where the card doesn't even respond to HPI it
cannot serve any request, thereby, this commit reset the
card in such catastrophic cases.
Change-Id: Idbca6ff3a420a954c61cf4fb79c9094542888d89
Signed-off-by: Talel Shenhar <tatias@codeaurora.org>
This change allows the usage of quirks based on
the register value of EXT_CSD_REV. It was seen for several
eMMC cards that same issues, such as data corruption
while using cache, were relevant for all eMMC cards
having the same EXT_CSD_REV value.
This change allows us to distinguish between cards based
on this register.
Change-Id: I1663891c367a59b520bc505641c6c4ddad56fd1a
Signed-off-by: Talel Shenhar <tatias@codeaurora.org>
With some bad SD cards, it is possible that the error recovery
procedure goes into a state where it retries the failed command
infinitely leading to CPU hog.
Fix inifinite retries when the bad SD card isn't responding to
a command even when the SD card reset mechanism is successful.
CRs-Fixed: 671153
Change-Id: Ic6db66b571aa425aec32c82d52789c68fe0cb0e9
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
[merez@codeaurora.org: fix conflicts due to removal of sanitize
from block.c 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>
When handling a DISCARD operation, the MMC request data structure may be
freed in memory. Therefore, it can't be used to retrieve the cmd_flags
for checking if MMC_REQ_NOREINSERT_MASK is set:
(!(mq->mqrq_cur->req->cmd_flags & MMC_REQ_NOREINSERT_MASK)))).
To prevent the issue we should use the local variable of cmd_flags.
Change-Id: Idef53d5bd66fa6f1faaf79644c8efb5177c75e89
Signed-off-by: Maya Erez <merez@codeaurora.org>
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
[merez@codeaurora.org: fix conflicts due to removal of stop transmission]
Signed-off-by: Maya Erez <merez@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>
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 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>
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>
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>
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>
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>
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>
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>
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 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>
