linux.git/drivers/mmc/card/queue.c, branch v3.15.1

Fix uses of dma_max_pfn() when converting to a limiting address

2014-02-17T23:08:41+00:00

We must use a 64-bit for this, otherwise overflowed bits get lost, and
that can result in a lower than intended value set.

Fixes: 8e0cb8a1f6ac ("ARM: 7797/1: mmc: Use dma_max_pfn(dev) helper for bounce_limit calculations")
Fixes: 7d35496dd982 ("ARM: 7796/1: scsi: Use dma_max_pfn(dev) helper for bounce_limit calculations")
Tested-Acked-by: Santosh Shilimkar 
Reviewed-by: Ulf Hansson 
Signed-off-by: Russell King

ARM: 7797/1: mmc: Use dma_max_pfn(dev) helper for bounce_limit calculations

2013-10-31T14:49:27+00:00

DMA bounce limit is the maximum direct DMA'able memory beyond which
bounce buffers has to be used to perform dma operations. MMC queue layr
relies on dma_mask but its calculation is based on max_*pfn which
don't have uniform meaning across architectures. So make use of
dma_max_pfn() which is expected to return the DMAable maximum pfn
value across architectures.

Cc: Chris Ball 
Signed-off-by: Santosh Shilimkar 
Signed-off-by: Russell King

mmc: card: Adding support for sanitize in eMMC 4.5

2013-05-26T18:23:13+00:00

The sanitize support is added as a user-app ioctl call, and
was removed from the block-device request, since its purpose is
to be invoked not via File-System but by a user.

This feature deletes the unmap memory region of the eMMC card,
by writing to a specific register in the EXT_CSD.

unmap region is the memory region that was previously deleted
(by erase, trim or discard operation).

In order to avoid timeout when sanitizing large-scale cards,
the timeout for sanitize operation is 240 seconds.

Signed-off-by: Yaniv Gardi 
Signed-off-by: Maya Erez 
Signed-off-by: Chris Ball

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

mmc: queue: exclude asynchronous transfer for special request

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

Unlike normal r/w request, special requests(discard, flush)
is finished with a one-time issue_fn. Request change to
mqrq_prev makes unnecessary call.

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

mmc: queue: amend buffer swap for non-blocking transfer

2012-12-06T18:54:37+00:00

In case both 'req' and 'mq->mqrq_prev->req' are null, there is no request
to be processed. That means there is no need to switch buffer.
Switching buffer is required only after finishing 'issue_fn'.

Signed-off-by: Seungwon Jeon 
Reviewed-by: Per Forlin 
Tested-by: Johan Rudholm 
Signed-off-by: Chris Ball

mmc: queue: remove redundant memsets

2012-05-09T14:10:46+00:00

Not needed to memset, as they are pointers and are assigned
to proper values in the next line anyway.

Signed-off-by: Venkatraman S 
Reviewed-by: Namjae Jeon 
Signed-off-by: Chris Ball

mmc: queue: rename mmc_request function

2012-05-09T14:08:54+00:00

The name mmc_request is used for both the issue function
and a data structure, which creates conflicts in symbol lookups
in editors. Rename the function to mmc_request_fn.

Signed-off-by: Venkatraman S 
Reviewed-by: Namjae Jeon 
Signed-off-by: Chris Ball