kernel.git/drivers/mmc/card/block.c, branch linux-3.1.y

block: separate priority boosting from REQ_META

2011-08-23T12:50:29Z

Add a new REQ_PRIO to let requests preempt others in the cfq I/O schedule, and lave REQ_META purely for marking requests as metadata in blktrace. All existing callers of REQ_META except for XFS are updated to also set REQ_PRIO for now. Signed-off-by: Christoph Hellwig Reviewed-by: Namhyung Kim Signed-off-by: Jens Axboe

mmc: block: fixed NULL pointer dereference

2011-07-21T14:35:00Z

We already check for ongoing async transfers when handling discard requests, but not in mmc_blk_issue_flush(). This patch fixes that omission. Tested with an SDHCI controller and eMMC4.41. Signed-off-by: Jaehoon Chung Signed-off-by: Kyungmin Park Acked-by: Per Forlin Cc: Signed-off-by: Chris Ball

mmc: block: add handling for two parallel block requests in issue_rw_rq

2011-07-20T21:21:15Z

Change mmc_blk_issue_rw_rq() to become asynchronous. The execution flow looks like this: * The mmc-queue calls issue_rw_rq(), which sends the request to the host and returns back to the mmc-queue. * The mmc-queue calls issue_rw_rq() again with a new request. * This new request is prepared in issue_rw_rq(), then it waits for the active request to complete before pushing it to the host. * When the mmc-queue is empty it will call issue_rw_rq() with a NULL req to finish off the active request without starting a new request. Signed-off-by: Per Forlin Acked-by: Kyungmin Park Acked-by: Arnd Bergmann Reviewed-by: Venkatraman S Tested-by: Sourav Poddar Tested-by: Linus Walleij Signed-off-by: Chris Ball

mmc: block: move error path in issue_rw_rq to a separate function.

2011-07-20T21:21:14Z

Break out code without functional changes. This simplifies the code and makes way for handling two parallel requests. Signed-off-by: Per Forlin Acked-by: Kyungmin Park Acked-by: Arnd Bergmann Reviewed-by: Venkatraman S Tested-by: Sourav Poddar Tested-by: Linus Walleij Signed-off-by: Chris Ball

mmc: block: add a block request prepare function

2011-07-20T21:21:13Z

Break out code from mmc_blk_issue_rw_rq to create a block request prepare function. This doesn't change any functionallity. This helps when handling more than one active block request. Signed-off-by: Per Forlin Acked-by: Kyungmin Park Acked-by: Arnd Bergmann Reviewed-by: Venkatraman S Tested-by: Sourav Poddar Tested-by: Linus Walleij Signed-off-by: Chris Ball

mmc: block: add member in mmc queue struct to hold request data

2011-07-20T21:21:13Z

The way the request data is organized in the mmc queue struct, it only allows processing of one request at a time. This patch adds a new struct to hold mmc queue request data such as sg list, request, blk request and bounce buffers, and updates any functions depending on the mmc queue struct. This prepares for using multiple active requests in one mmc queue. Signed-off-by: Per Forlin Acked-by: Kyungmin Park Acked-by: Arnd Bergmann Reviewed-by: Venkatraman S Tested-by: Sourav Poddar Tested-by: Linus Walleij Signed-off-by: Chris Ball

mmc: block: add checking of r/w command response

2011-07-20T21:20:55Z

Check the status bits in the r/w command response for any errors. If error bits are set, then we won't have seen any data transferred, so it's pointless doing any further checking. Signed-off-by: Russell King Acked-by: Linus Walleij Tested-by: Pawel Moll Signed-off-by: Chris Ball

mmc: block: improve error recovery from command channel errors

2011-07-20T21:20:54Z

Command channel errors fall into four classes: 1. The command was issued with the card in the wrong state 2. The command failed to be received by the card correctly 3. The cards response failed to be received by the host (CRC error) 4. The card failed to respond to the card For (1), in theory we should know that the card is in the correct state. However, a failed stop command (or other failure) may result in the card remaining in a data transfer state from the previous command. If we detect this condition, we try to recover by sending a stop command. For the initial commands (set block count and the read/write command) no data will have been transferred. All that we need deal with is retrying at this point. A failed stop command can be remedied as above. If we are unable to recover the card (eg, the card ignores our requests for status, or we don't recognise the error code) then we immediately fail the request. Signed-off-by: Russell King Acked-by: Linus Walleij Tested-by: Pawel Moll Signed-off-by: Chris Ball

mmc: block: allow get_card_status() to return error status

2011-07-20T21:20:54Z

If the MMC_SEND_STATUS command is not successful, we should not return a zero status word, but instead allow the caller to know positively that an error occurred. Convert the open-coded get_card_status() to use the helper function, and provide definitions for the card state field. Signed-off-by: Russell King Acked-by: Linus Walleij Tested-by: Pawel Moll Signed-off-by: Chris Ball

mmc: queue: append partition subname to queue thread name

2011-06-25T22:52:57Z

For example, an eMMC with 2 boot partitions will have 3 threads. The names change from: 40 ? 00:00:00 mmcqd/0 41 ? 00:00:00 mmcqd/0 42 ? 00:00:00 mmcqd/0 to: 40 ? 00:00:00 mmcqd/0 41 ? 00:00:00 mmcqd/0boot0 42 ? 00:00:00 mmcqd/0boot1 Signed-off-by: Adrian Hunter Cc: Andrei Warkentin Signed-off-by: Chris Ball