- 13 2月, 2017 3 次提交
-
-
由 Geert Uytterhoeven 提交于
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Geert Uytterhoeven 提交于
With gcc-4.1.2: mmc/core/block.c: In function ‘mmc_blk_issue_discard_rq’: mmc/core/block.c:1150: warning: ‘arg’ may be used uninitialized in this function mmc/core/block.c:1150: warning: ‘nr’ may be used uninitialized in this function mmc/core/block.c:1150: warning: ‘from’ may be used uninitialized in this function While this is a false positive, it can be avoided easily by jumping over the checks for "err" that are always false. Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Jungseung Lee 提交于
In the eMMC 5.0 version of the spec, several EXT_CSD fields about device lifetime are added. - Two types of estimated indications reflected by averaged wear out of memory - An indication reflected by average reserved blocks Export the information through sysfs. Signed-off-by: NJungseung Lee <js07.lee@samsung.com> Reviewed-by: NJaehoon Chung <jh80.chung@samsung.com> Reviewed-by: NShawn Lin <shawn.lin@rock-chips.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
- 16 1月, 2017 1 次提交
-
-
由 Ulf Hansson 提交于
Regressions for not being able to detect an eMMC HS DDR mode card has been reported for the sdhci-esdhc-imx driver, but potentially other sdhci variants may suffer from the similar problem. The commit e173f891 ("mmc: core: Update CMD13 polling policy when switch to HS DDR mode"), is causing the problem. It seems that change moved one step to far, regarding changing the host's timing before polling for a busy card. To fix this, let's move back to the behaviour when the host's timing is updated after the polling, but before the switch status is fetched and validated. In cases when polling with CMD13, we keep validating the switch status at each attempt. However, to align with the other card busy detections mechanism, let's fetch and validate the switch status also after the host's timing is updated. Reported-by: NClemens Gruber <clemens.gruber@pqgruber.com> Reported-by: NGary Bisson <gary.bisson@boundarydevices.com> Fixes: e173f891 ("mmc: core: Update CMD13 polling policy when switch..") Cc: Shawn Lin <shawn.lin@rock-chips.com> Cc: Dong Aisheng <aisheng.dong@nxp.com> Cc: Haibo Chen <haibo.chen@nxp.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Tested-by: NClemens Gruber <clemens.gruber@pqgruber.com> Tested-by: NJagan Teki <jagan@amarulasolutions.com> Reviewed-by: NShawn Lin <shawn.lin@rock-chips.com> Tested-by: NHaibo Chen <haibo.chen@nxp.com> Reviewed-by: NDong Aisheng <aisheng.dong@nxp.com>
-
- 25 12月, 2016 1 次提交
-
-
由 Linus Torvalds 提交于
This was entirely automated, using the script by Al: PATT='^[[:blank:]]*#[[:blank:]]*include[[:blank:]]*<asm/uaccess.h>' sed -i -e "s!$PATT!#include <linux/uaccess.h>!" \ $(git grep -l "$PATT"|grep -v ^include/linux/uaccess.h) to do the replacement at the end of the merge window. Requested-by: NAl Viro <viro@zeniv.linux.org.uk> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 21 12月, 2016 1 次提交
-
-
由 Paul Burton 提交于
The mmc_read_ssr() function results in DMA to the raw_ssr member of struct mmc_card, which is not guaranteed to be cache line aligned & thus might not meet the requirements set out in Documentation/DMA-API.txt: Warnings: Memory coherency operates at a granularity called the cache line width. In order for memory mapped by this API to operate correctly, the mapped region must begin exactly on a cache line boundary and end exactly on one (to prevent two separately mapped regions from sharing a single cache line). Since the cache line size may not be known at compile time, the API will not enforce this requirement. Therefore, it is recommended that driver writers who don't take special care to determine the cache line size at run time only map virtual regions that begin and end on page boundaries (which are guaranteed also to be cache line boundaries). On some systems where DMA is non-coherent this can lead to us losing data that shares cache lines with the raw_ssr array. Fix this by kmalloc'ing a temporary buffer to perform DMA into. kmalloc will ensure the buffer is suitably aligned, allowing the DMA to be performed without any loss of data. Signed-off-by: NPaul Burton <paul.burton@imgtec.com> Fixes: 5275a652 ("mmc: sd: Export SD Status via “ssr” device attribute") Cc: <stable@vger.kernel.org> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
- 20 12月, 2016 1 次提交
-
-
由 Adrian Hunter 提交于
Commit e0097cf5 ("mmc: queue: Fix queue thread wake-up") did not go far enough. mmc_wait_for_data_req_done() still contains some problems and can be further simplified. First it should not touch context_info->is_waiting_last_req because that is a wake-up control used by the owner of the context. Secondly, it should always return when one of its wake-up conditions is met because, again, that is contolled by the owner of the context. While the current block driver does not have an issue, these problems were exposed during testing of the Software Command Queue patches. Fixes: e0097cf5 ("mmc: queue: Fix queue thread wake-up") Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com> Tested-by: NHarjani Ritesh <riteshh@codeaurora.org> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
- 12 12月, 2016 1 次提交
-
-
由 Ulf Hansson 提交于
Once upon a time it made sense to keep the mmc block device driver and its related code, in its own directory called card. Over time, more an more functions/structures have become shared through generic mmc header files, between the core and the card directory. In other words, the relationship between them has become closer. By sharing functions/structures via generic header files, it becomes easy for outside users to abuse them. In a way to avoid that from happen, let's move the files from card directory into the core directory, as it enables us to move definitions of functions/structures into mmc core specific header files. Note, this is only the first step in providing a cleaner mmc interface for outside users. Following changes will do the actual cleanup, as that is not part of this change. Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 05 12月, 2016 9 次提交
-
-
由 Adrian Hunter 提交于
If a tuning command times out, the card could still be processing it, which will cause problems for recovery. The eMMC specification says that CMD12 can be used to stop CMD21, so add a function that does that. Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Adrian Hunter 提交于
The JEDEC specification indicates CMD13 can be used after a HS200 switch to check for errors. However in practice some boards experience CRC errors in the CMD13 response. Consequently, for HS200, CRC errors are not a reliable way to know the switch failed. If there really is a problem, we would expect tuning will fail and the result ends up the same. So change the error condition to ignore CRC errors in that case. Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com> Acked-by: NJaehoon Chung <jh80.chung@samsung.com> Reviewed-by: NShawn Lin <shawn.lin@rock-chips.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Shawn Lin 提交于
BUG_ONs doesn't help anything except for stop the system from running. If it occurs, it implies we should deploy proper error handling for that. So this patch is gonna discard these meaningless BUG_ONs and deploy error handling if needed. Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Shawn Lin 提交于
BUG_ONs doesn't help anything except for stop the system from running. If it occurs, it implies we should deploy proper error handling for that. So this patch is gonna discard these meaningless BUG_ONs and deploy error handling if needed. Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Shawn Lin 提交于
BUG_ONs doesn't help anything except for stop the system from running. If it occurs, it implies we should deploy proper error handling for that. So this patch is gonna discard these meaningless BUG_ONs and deploy error handling if needed. Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Shawn Lin 提交于
Return error value for file_operations callback instead of triggering BUG_ON which is meaningless. Personally I don't believe n != EXT_CSD_STR_LEN could happen. Anyway, propagate the error to the caller. Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Shawn Lin 提交于
BUG_ONs doesn't help anything except for stop the system from running. If it occurs, it implies we should deploy proper error handling for that. So this patch is gonna discard these meaningless BUG_ONs and deploy error handling if needed. Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Adrian Hunter 提交于
Add definitions relating to Command Queuing. Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com> Reviewed-by: NLinus Walleij <linus.walleij@linaro.org> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Adrian Hunter 提交于
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: NAdrian Hunter <adrian.hunter@intel.com> Reviewed-by: NLinus Walleij <linus.walleij@linaro.org> Reviewed-by: NHarjani Ritesh <riteshh@codeaurora.org> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
- 29 11月, 2016 15 次提交
-
-
由 Linus Walleij 提交于
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: NLinus Walleij <linus.walleij@linaro.org> Acked-by: NJaehoon Chung <jh80.chung@samsung.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Ulf Hansson 提交于
According to the JEDEC specification, during bus timing change operations for mmc, sending a CMD13 could trigger CRC errors. As switching to HS DDR mode indeed causes a bus timing change, polling with CMD13 to detect card busy, may thus potentially trigger CRC errors. Currently these errors are treated as the switch to HS DDR mode failed. To improve this behaviour, let's instead tell __mmc_switch() to retry when it encounters CRC errors during polling. Moreover, when switching to HS DDR mode, let's make sure the CMD13 polling is done by having the mmc host and the mmc card, being configured to operate at the same selected bus speed timing. Fix this by providing MMC_TIMING_MMC_DDR52 as the timing parameter to __mmc_switch(). Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Tested-by: NLinus Walleij <linus.walleij@linaro.org> Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
-
由 Ulf Hansson 提交于
In cases when the mmc host doesn't support HW busy detection, polling for a card being busy by using CMD13 is beneficial. That is because, instead of waiting a fixed amount of time, 500ms or the generic CMD6 time from EXT_CSD, we find out a lot sooner when the card stops signaling busy. This leads to a significant decreased total initialization time for the mmc card. However, to allow polling with CMD13 during a bus timing change operation, such as switching to HS mode, we first need to update the mmc host's bus timing before starting to poll. Deal with that, simply by providing MMC_TIMING_MMC_HS as the timing parameter to __mmc_switch() from mmc_select_hs(). By telling __mmc_switch() to allow polling with CMD13, also makes it validate the CMD6 status, thus we can remove the corresponding checks. When switching to HS400ES, the mmc_select_hs() function is called in one of the intermediate steps. To still prevent CMD13 polling for HS400ES, let's call the __mmc_switch() function in this path as it enables us to keep using the existing method. Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Tested-by: NLinus Walleij <linus.walleij@linaro.org> Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
-
由 Ulf Hansson 提交于
In cases when a speed mode change is requested for mmc cards, a CMD6 is sent by calling __mmc_switch() during the card initialization. The CMD6 leads to the card entering a busy period. When that is completed, the host must parse the CMD6 status to find out whether the change of the speed mode succeeded. To enable the mmc core to poll the card by using CMD13 to find out when the busy period is completed, it's reasonable to make sure polling is done by having the mmc host and the mmc card, being configured to operate at the same selected bus speed timing. Therefore, let's extend __mmc_switch() to take yet another parameter, which allow its callers to update the bus speed timing of the mmc host. In this way, __mmc_switch() also becomes capable of reading and validating the CMD6 status by sending a CMD13, in cases when that's desired. If __mmc_switch() encounters a failure, we make sure to restores the old bus speed timing for the mmc host, before propagating the error code. Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Tested-by: NLinus Walleij <linus.walleij@linaro.org> Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
-
由 Ulf Hansson 提交于
According to the JEDEC specification, the SWITCH_ERROR bit in the device status from a R1 response, is an error bit which may be cleared as soon as the response that reports the error is sent. When polling with CMD13 to find out when the card stops signaling busy after a CMD6 has been sent, we currently parse only the last CMD13 response for the SWITCH_ERROR bit. Consequentially we could loose important information about the card. In worst case if the card stops signaling busy within the allowed timeout, we could end up believing that the CMD6 command completed successfully, when in fact it didn't. To improve the behaviour, let's parse each CMD13 response to see if the SWITCH_ERROR bit is set in the device status. In such case, we abort the polling loop and report the error. Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Tested-by: NLinus Walleij <linus.walleij@linaro.org> Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
-
由 Ulf Hansson 提交于
The ignore_crc parameter/variable name is used at a couple of places in the mmc core. Let's rename it to retry_crc_err to reflect its new purpose. Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Tested-by: NLinus Walleij <linus.walleij@linaro.org> Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
-
由 Ulf Hansson 提交于
There are only one users left which calls __mmc_send_status(). Moreover, the ignore_crc parameter isn't being used, so let's just remove these redundant parts. Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Tested-by: NLinus Walleij <linus.walleij@linaro.org> Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
-
由 Ulf Hansson 提交于
After a CMD6 command has been sent, the __mmc_switch() function might be advised to poll the card for busy by using CMD13 and also by ignoring CRC errors. In the case of ignoring CRC errors, the mmc core tells the mmc host to also ignore these errors via masking the MMC_RSP_CRC response flag. This seems wrong, as it leads to that the mmc host could propagate an unreliable response, instead of a proper error code. What we really want, is not to ignore CRC errors but instead retry the polling attempt. So, let's change this by treating a CRC error as the card is still being busy and thus continue to run the polling loop. Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Tested-by: NLinus Walleij <linus.walleij@linaro.org> Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
-
由 Linus Walleij 提交于
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 <linux/mmc/core.h> 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 <zhang.chunyan@linaro.org> Cc: Baolin Wang <baolin.wang@linaro.org> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Ulf Hansson 提交于
The MMC_CAP2_NO_PRESCAN_POWERUP was invented to avoid running the power up sequence, mmc_power_up(), during ->probe() of the mmc host driver, but instead defer this to the mmc detect work. This is especially useful for those hosts that suffers from a long initialization time, as this time would otherwise add up to the total boot time. However, due to the introduction of runtime PM of mmc host devices in the mmc core, this behaviour changed a bit. More precisely, it caused the mmc core to runtime resume the host device during ->probe() of the host driver. In cases like the rtsx_usb_sdmmc, runtime resuming the device may be costly and thus affecting the total boot time. To improve this behaviour when using MMC_CAP2_NO_PRESCAN_POWERUP, let's postpone also calling mmc_power_off() when starting the host. This change allows the mmc core to avoid runtime resuming the device, as it don't need to claim the host for that execution path. Cc: Ritesh Raj Sarraf <rrs@researchut.com> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Shawn Lin 提交于
Add new helper API mmc_can_gpio_cd for slot-gpio to make host drivers know whether it supports gpio card detect. Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com> Signed-off-by: NJaehoon Chung <jh80.chung@samsung.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Ulf Hansson 提交于
When polling for busy after sending a MMC_SWITCH command, both the optional ->card_busy() callback and CMD13 are being used in conjunction. This doesn't make sense. Instead it's more reasonable to rely solely on the ->card_busy() callback when it exists. Let's change that and instead use the CMD13 as a fall-back. In this way we avoid sending CMD13, unless it's really needed. Within this context, let's also take the opportunity to make some additional clean-ups and clarifications to the related code. Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Acked-by: NJaehoon Chung <jh80.chung@samsung.com> Tested-by: NJaehoon Chung <jh80.chung@samsung.com>
-
由 Ulf Hansson 提交于
In yet another step of cleaning up __mmc_switch(), let's factor out the code that deals with card busy polling. Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Acked-by: NJaehoon Chung <jh80.chung@samsung.com> Tested-by: NJaehoon Chung <jh80.chung@samsung.com>
-
由 Ulf Hansson 提交于
The __mmc_switch() deserves a clean-up. In this step, let's move some code outside of the do-while loop, which deal deals with the card busy polling. This change simplifies the code in that sense that it becomes easier to follow what is being executed during card busy polling, but it also gives a better understanding for when polling isn't done. Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Acked-by: NJaehoon Chung <jh80.chung@samsung.com> Tested-by: NJaehoon Chung <jh80.chung@samsung.com>
-
由 Ulf Hansson 提交于
Following changes needs mmc_switch_status() to be available both from mmc.c and mmc_ops.c. Allow that by moving its implementation to mmc_ops.c and make it available via mmc_ops.h. Moving mmc_switch_status() to mmc_ops.c, also enables us to turn mmc_switch_status_error() into static function. So let's take the opportunity to change this as well. Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Acked-by: NJaehoon Chung <jh80.chung@samsung.com> Tested-by: NJaehoon Chung <jh80.chung@samsung.com>
-
- 07 11月, 2016 1 次提交
-
-
由 Ulf Hansson 提交于
In the eMMC 4.51 version of the spec, an EXT_CSD field called GENERIC_CMD6_TIME[248] was added. This allows cards to specify the maximum time it may need to move out from its busy state, when a CMD6 command has been sent. In cases when the card is compliant to versions < 4.51 of the eMMC spec, obviously the core needs to use a fall-back value for this timeout, which currently is set to 10 minutes. This value is completely in the wrong range and importantly in some cases it causes a card initialization to take more than 10 minute to complete. Earlier this scenario was avoided as the mmc core used CMD13 to poll the card, to find out when it stopped signaling busy. Commit 08573eaf ("mmc: mmc: do not use CMD13 to get status after speed mode switch") changed this behavior. Instead of reverting that commit, which would cause other issues, let's instead start by picking a simple solution for the problem, by using a 500ms default generic CMD6 timeout. The reason for using exactly 500ms, comes from observations that shows it's quite common for cards to specify 250ms. 500ms is two times that value so likely it should be enough for most cards. Cc: <stable@vger.kernel.org> # v4.8+ Fixes: 08573eaf ("mmc: mmc: do not use CMD13 to get status after speed mode switch") Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Tested-by: NStephen Boyd <sboyd@codeaurora.org> Tested-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 10 10月, 2016 2 次提交
-
-
由 Shawn Lin 提交于
Per JESD84-B51 P49, Host need to change frequency to <=52MHz after setting HS_TIMING to 0x1, and host may changes frequency to <= 200MHz after setting HS_TIMING to 0x3. That means the card expects the clock rate to increase from the current used f_init (which is less than 400KHz, but still being less than 52MHz) to 52MHz, otherwise we find some eMMC devices significantly report failure when sending status. Reported-by: NXiao Yao <xiaoyao@rock-chips.com> Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com> Reviewed-by: NDouglas Anderson <dianders@chromium.org> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Shawn Lin 提交于
When introducing hs400es, I didn't notice that we haven't switched voltage to 1V2 or 1V8 for it. That happens to work as the first controller claiming to support hs400es, arasan(5.1), which is designed to only support 1V8. So the voltage is fixed to 1V8. But it actually is wrong, and will not fit for other host controllers. Let's fix it. Fixes: commit 81ac2af6 ("mmc: core: implement enhanced strobe support") Cc: <stable@vger.kernel.org> Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com> Reviewed-by: NDouglas Anderson <dianders@chromium.org> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
- 27 9月, 2016 5 次提交
-
-
由 Ziyuan Xu 提交于
Per spec, block size should always be 512 bytes for dual rate mode, so any attempts to switch the block size under dual rate mode should be neglected. Signed-off-by: NZiyuan Xu <xzy.xu@rock-chips.com> Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Adrian Hunter 提交于
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: NAdrian Hunter <adrian.hunter@intel.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Baolin Wang 提交于
In most cases the 'card->erase_size' is power of 2, then the round_up/down() function is more efficient than '%' operation when the 'card->erase_size' is power of 2. Signed-off-by: NBaolin Wang <baolin.wang@linaro.org> Tested-by: NShawn Lin <shawn.lin@rock-chips.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Baolin Wang 提交于
In order to clean up the mmc_erase() function and do some optimization for erase size alignment, factor out the guts of erase size alignment into mmc_align_erase_size() function. Signed-off-by: NBaolin Wang <baolin.wang@linaro.org> Tested-by: NShawn Lin <shawn.lin@rock-chips.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Ulf Hansson 提交于
In cases when the host->max_busy_timeout isn't specified, the calculated number of maximum discard sectors defaults to UINT_MAX. This may cause a too long timeout for a discard request. Avoid this by using a default maximum erase timeout of 60s, used when we calculate the maximum number of sectors that are allowed to be discarded per request. Do note that the minimum number of sectors to be discarded is still at least one "preferred erase size". Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Reviewed-by: NShawn Lin <shawn.lin@rock-chips.com>
-