linux.git/drivers/mmc/card/queue.h, branch v4.9

mmc: core: Annotate cmd_hdr as __le32

2016-10-10T12:14:49+00:00

Commit f68381a70bb2 (mmc: block: fix packed command header endianness)
correctly fixed endianness handling of packed_cmd_hdr in
mmc_blk_packed_hdr_wrq_prep.

But now, sparse complains about incorrect types:
drivers/mmc/card/block.c:1613:27: sparse: incorrect type in assignment (different base types)
drivers/mmc/card/block.c:1613:27:    expected unsigned int [unsigned] [usertype] 
drivers/mmc/card/block.c:1613:27:    got restricted __le32 [usertype] 
...

So annotate cmd_hdr properly using __le32 to make everyone happy.

Signed-off-by: Jiri Slaby 
Fixes: f68381a70bb2 (mmc: block: fix packed command header endianness)
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson

mmc: card: do away with indirection pointer

2016-09-26T19:31:31+00:00

We have enough vtables in the kernel as it is, we don't need
this one to create even more artificial separation of concerns.

As is proved by the Makefile:

obj-$(CONFIG_MMC_BLOCK)         += mmc_block.o
mmc_block-objs                  := block.o queue.o

block.c and queue.c are baked into the same mmc_block.o object.
So why would one of these objects access a function in the
other object by dereferencing a pointer?

Create a new block.h header file for the single shared function
from block to queue and remove the function pointer and just
call the queue request function.

Apart from making the code more readable, this also makes link
optimizations possible and probably speeds up the call as well.

Signed-off-by: Linus Walleij 
Signed-off-by: Ulf Hansson

block: Fix secure erase

2016-08-16T15:16:51+00:00

Commit 288dab8a35a0 ("block: add a separate operation type for secure
erase") split REQ_OP_SECURE_ERASE from REQ_OP_DISCARD without considering
all the places REQ_OP_DISCARD was being used to mean either. Fix those.

Signed-off-by: Adrian Hunter 
Fixes: 288dab8a35a0 ("block: add a separate operation type for secure erase")
Signed-off-by: Jens Axboe

block, drivers: add REQ_OP_FLUSH operation

2016-06-07T19:41:38+00:00

This adds a REQ_OP_FLUSH operation that is sent to request_fn
based drivers by the block layer's flush code, instead of
sending requests with the request->cmd_flags REQ_FLUSH bit set.

Signed-off-by: Mike Christie 
Reviewed-by: Christoph Hellwig 
Reviewed-by: Hannes Reinecke 
Signed-off-by: Jens Axboe

drivers: use req op accessor

2016-06-07T19:41:38+00:00

The req operation REQ_OP is separated from the rq_flag_bits
definition. This converts the block layer drivers to
use req_op to get the op from the request struct.

Signed-off-by: Mike Christie 
Reviewed-by: Hannes Reinecke 
Signed-off-by: Jens Axboe

mmc: block: Retry errored data requests when re-tuning is needed

2015-06-01T07:06:59+00:00

Retry errored data requests when re-tuning is needed and
add a flag to struct mmc_blk_request so that the retry
is only done once.

Signed-off-by: Adrian Hunter 
Signed-off-by: Ulf Hansson

mmc: card: Don't access RPMB partitions for normal read/write

2015-05-06T12:55:12+00:00

During kernel boot, it will try to read some logical sectors
of each block device node for the possible partition table.

But since RPMB partition is special and can not be accessed
by normal eMMC read / write CMDs, it will cause below error
messages during kernel boot:
...
 mmc0: Got data interrupt 0x00000002 even though no data operation was in progress.
 mmcblk0rpmb: error -110 transferring data, sector 0, nr 32, cmd response 0x900, card status 0xb00
 mmcblk0rpmb: retrying using single block read
 mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
 mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
 mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
 mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
 mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
 mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
 end_request: I/O error, dev mmcblk0rpmb, sector 0
 Buffer I/O error on device mmcblk0rpmb, logical block 0
 end_request: I/O error, dev mmcblk0rpmb, sector 8
 Buffer I/O error on device mmcblk0rpmb, logical block 1
 end_request: I/O error, dev mmcblk0rpmb, sector 16
 Buffer I/O error on device mmcblk0rpmb, logical block 2
 end_request: I/O error, dev mmcblk0rpmb, sector 24
 Buffer I/O error on device mmcblk0rpmb, logical block 3
...

This patch will discard the access request in eMMC queue if
it is RPMB partition access request. By this way, it avoids
trigger above error messages.

Fixes: 090d25fe224c ("mmc: core: Expose access to RPMB partition")
Signed-off-by: Yunpeng Gao 
Signed-off-by: Chuanxiao Dong 
Tested-by: Michael Shigorin 
Signed-off-by: Ulf Hansson

mmc: block: fix the host's claim-release in special request

2013-03-22T17:29:36+00:00

For normal request mmc_blk_issue_rq is called twice with asynchronous
transfer(cur and prev). Host's claim and release can be done in each
mmc_blk_issue_rq. However, Special request is currently excluded in
asynchronous transfer. After special request is finished, if there is
no new request, mmc_release_host won't be called in mmc_blk_issue_rq.
The problem is founded during mmc_suspend.

[] (__schedule+0x0/0x78c) from [] (schedule+0x38/0x78)
[] (schedule+0x0/0x78) from [] (__mmc_claim_host+0xac/0x1b4)
[] (__mmc_claim_host+0x0/0x1b4) from [] (mmc_suspend+0x28/0x9c)
[] (mmc_suspend+0x0/0x9c) from [] (mmc_suspend_host+0xb4/0x194)
...

Reported-by: Johan Rudholm 
Signed-off-by: Seungwon Jeon 
Tested-by: Johan Rudholm 
Signed-off-by: Chris Ball

mmc: support packed write command for eMMC4.5 devices

2013-02-24T19:37:16+00:00

This patch supports packed write command of eMMC4.5 devices.  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. Large amounts of
data in one transfer rather than several data of small size are
effective for eMMC write internally.  As a result, packed command help
write throughput be improved.  The following tables show the results
of packed write.

Type A:
test     none |  packed
iozone   25.8 |  31
tiotest  27.6 |  31.2
lmdd     31.2 |  35.4

Type B:
test     none |  packed
iozone   44.1 |  51.1
tiotest  47.9 |  52.5
lmdd     51.6 |  59.2

Type C:
test     none |  packed
iozone   19.5 |  32
tiotest  19.9 |  34.5
lmdd     22.8 |  40.7

Signed-off-by: Seungwon Jeon 
Reviewed-by: Maya Erez 
Reviewed-by: Namjae Jeon 
Signed-off-by: Chris Ball

mmc: fix async request mechanism for sequential read scenarios

2013-02-11T18:28:49+00:00

When current request is running on the bus and if next request fetched
by mmcqd is NULL, mmc context (mmcqd thread) gets blocked until the
current request completes. This means that if new request comes in while
the mmcqd thread is blocked, this new request can not be prepared in
parallel to current ongoing request. This may result in delaying the new
request execution and increase it's latency.

This change allows to wake up the MMC thread on new request arrival.
Now once the MMC thread is woken up, a new request can be fetched and
prepared in parallel to the current running request which means this new
request can be started immediately after the current running request
completes.

With this change read throughput is improved by 16%.

Signed-off-by: Konstantin Dorfman 
Reviewed-by: Seungwon Jeon 
Signed-off-by: Chris Ball