kernel/linux.git/include/linux/mmc/host.h, branch v4.10.2

mmc: queue: Fix queue thread wake-up

2016-12-05T09:31:03+00:00

The only time the driver sleeps expecting to be woken upon the arrival of a new request, is when the dispatch queue is empty. The only time that it is known whether the dispatch queue is empty is after NULL is returned from blk_fetch_request() while under the queue lock. Recognizing those facts, simplify the synchronization between the queue thread and the request function. A couple of flags tell the request function what to do, and the queue lock and barriers associated with wake-ups ensure synchronization. The result is simpler and allows the removal of the context_info lock. Signed-off-by: Adrian Hunter Reviewed-by: Linus Walleij Reviewed-by: Harjani Ritesh Signed-off-by: Ulf Hansson

mmc: block: delete packed command support

2016-11-29T08:05:27+00:00

I've had it with this code now. The packed command support is a complex hurdle in the MMC/SD block layer, around 500+ lines of code which was introduced in 2013 in commit ce39f9d17c14 ("mmc: support packed write command for eMMC4.5 devices") commit abd9ac144947 ("mmc: add packed command feature of eMMC4.5") ...and since then it has been rotting. The original author of the code has disappeared from the community and the mail address is bouncing. For the code to be exercised the host must flag that it supports packed commands, so in mmc_blk_prep_packed_list() which is called for every single request, the following construction appears: u8 max_packed_rw = 0; if ((rq_data_dir(cur) == WRITE) && mmc_host_packed_wr(card->host)) max_packed_rw = card->ext_csd.max_packed_writes; if (max_packed_rw == 0) goto no_packed; This has the following logical deductions: - Only WRITE commands can really be packed, so the solution is only half-done: we support packed WRITE but not packed READ. The packed command support has not been finalized by supporting reads in three years! - mmc_host_packed_wr() is just a static inline that checks host->caps2 & MMC_CAP2_PACKED_WR. The problem with this is that NO upstream host sets this capability flag! No driver in the kernel is using it, and we can't test it. Packed command may be supported in out-of-tree code, but I doubt it. I doubt that the code is even working anymore due to other refactorings in the MMC block layer, who would notice if patches affecting it broke packed commands? No one. - There is no Device Tree binding or code to mark a host as supporting packed read or write commands, just this flag in caps2, so for sure there are not any DT systems using it either. It has other problems as well: mmc_blk_prep_packed_list() is speculatively picking requests out of the request queue with blk_fetch_request() making the MMC/SD stack harder to convert to the multiqueue block layer. By this we get rid of an obstacle. The way I see it this is just cruft littering the MMC/SD stack. Cc: Namjae Jeon Cc: Maya Erez Acked-by: Jaehoon Chung Signed-off-by: Linus Walleij Signed-off-by: Ulf Hansson

mmc: delete is_first_req parameter from pre-request callback

2016-11-29T08:05:27+00:00

The void (*pre_req) callback in the struct mmc_host_ops vtable is passing an argument "is_first_req" indicating whether this is the first request or not. None of the in-kernel users use this parameter: instead, since they all just do variants of dma_map* they use the DMA cookie to indicate whether a pre* callback has already been done for a request when they decide how to handle it. Delete the parameter from the callback and all users, as it is just pointless cruft. Signed-off-by: Linus Walleij Acked-by: Jaehoon Chung Signed-off-by: Ulf Hansson

mmc: core: Add helper to see if a host can be retuned

2016-11-29T08:00:54+00:00

This is in preparation for restoring saved tuning parameters when resuming the TMIO driver. Signed-off-by: Simon Horman Acked-by: Wolfram Sang Tested-by: Wolfram Sang Signed-off-by: Ulf Hansson

mmc: core: use enum mmc_blk_status properly

2016-11-29T08:00:51+00:00

There were several instances of code using the enum mmc_blk_status by arbitrarily converting it to an int and throwing it around to different functions. This makes the code hard to understand to may give rise to strange errors. Especially the function prototype mmc_start_req() had to be modified to take a pointer to an enum mmc_blk_status and the function pointer .err_check() inside struct mmc_async_req needed to return an enum mmc_blk_status. In every case: instead of assigning the block layer error code to an int, use the enum, also change the signature of all functions actually passing this enum to use the enum. To make it possible to use the enum everywhere applicable, move it to so that all code actually using it can also see it. An interesting case was encountered in the MMC test code which did not return a enum mmc_blk_status at all in the .err_check function supposed to check whether asynchronous requests worked or not: instead it returned a normal -ERROR or even the test frameworks internal error codes. The test code would also pass on enum mmc_blk_status codes as error codes inside the test code instead of converting them to the local RESULT_* codes. I have tried to fix all instances properly and run some tests on the result. Cc: Chunyan Zhang Cc: Baolin Wang Signed-off-by: Linus Walleij Signed-off-by: Ulf Hansson

mmc: core: Add support for sending commands during data transfer

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

A host controller driver exposes its capability using caps flag MMC_CAP_CMD_DURING_TFR. A driver with that capability can accept requests that are marked mrq->cap_cmd_during_tfr = true. Then the driver informs the upper layers when the command line is available for further commands by calling mmc_command_done(). Because of that, the driver will not then automatically send STOP commands, and it is the responsibility of the upper layer to send a STOP command if it is required. For requests submitted through the mmc_wait_for_req() interface, the caller sets mrq->cap_cmd_during_tfr = true which causes mmc_wait_for_req() in fact not to wait. The caller can then send commands that do not use the data lines. Finally the caller can wait for the transfer to complete by calling mmc_wait_for_req_done() which is now exported. For requests submitted through the mmc_start_req() interface, the caller again sets mrq->cap_cmd_during_tfr = true, but mmc_start_req() anyway does not wait. The caller can then send commands that do not use the data lines. Finally the caller can wait for the transfer to complete in the normal way i.e. calling mmc_start_req() again. Irrespective of how a cap_cmd_during_tfr request is started, mmc_is_req_done() can be called if the upper layer needs to determine if the request is done. However the appropriate waiting function (either mmc_wait_for_req_done() or mmc_start_req()) must still be called. The implementation consists primarily of a new completion mrq->cmd_completion which notifies when the command line is available for further commands. That completion is completed by mmc_command_done(). When there is an ongoing data transfer, calls to mmc_wait_for_req() will automatically wait on that completion, so the caller does not have to do anything special. Note, in the case of errors, the driver may call mmc_request_done() without calling mmc_command_done() because mmc_request_done() always calls mmc_command_done(). Signed-off-by: Adrian Hunter Signed-off-by: Ulf Hansson

mmc: core: Allow hosts to specify non-support for MMC commands

2016-07-25T08:34:47+00:00

Host drivers which needs to valdiate for non-supported MMC commands and returnn error code for such requests. To improve and simplify the behaviour, let's invent MMC_CAP2_NO_MMC which these host drivers can set to tell the mmc core to skip sending MMC commands during card initialization. Signed-off-by: Shawn Lin Signed-off-by: Ulf Hansson

mmc: core: Allow hosts to specify non-support for SD commands

2016-07-25T08:34:22+00:00

There are host drivers which needs to valdiate for non-supported SD commands and returnn error code for such requests. To improve and simplify the behaviour, let's invent MMC_CAP2_NO_SD which these host drivers can set to tell the mmc core to skip sending SD commands during card initialization. Signed-off-by: Ulf Hansson

mmc: core: implement enhanced strobe support

2016-07-25T08:34:05+00:00

Controllers use data strobe line to latch data from devices under hs400 mode, but not for cmd line. So since emmc 5.1, JEDEC introduces enhanced strobe mode for latching cmd response from emmc devices to host controllers. This new feature is optional, so it depends both on device's cap and host's cap to decide whether to use it or not. Signed-off-by: Shawn Lin Reviewed-by: Jaehoon Chung Tested-by: Douglas Anderson Tested-by: Jaehoon Chung Acked-by: Adrian Hunter Signed-off-by: Ulf Hansson

mmc: core: add mmc-hs400-enhanced-strobe support

2016-07-25T08:34:05+00:00

This patch introduce mmc-hs400-enhanced-strobe for platforms which want to enable enhanced strobe function from DT if the mmc host controller claims to support enhanced strobe. Signed-off-by: Shawn Lin Reviewed-by: Douglas Anderson Tested-by: Jaehoon Chung Signed-off-by: Ulf Hansson