Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12 |
|
#
51f5b305 |
| 13-Feb-2023 |
Ulf Hansson <ulf.hansson@linaro.org> |
mmc: core: Align to common busy polling behaviour for mmc ioctls
Let's align to the common busy polling behaviour for mmc ioctls, by updating the below two corresponding parts, that comes into play
mmc: core: Align to common busy polling behaviour for mmc ioctls
Let's align to the common busy polling behaviour for mmc ioctls, by updating the below two corresponding parts, that comes into play when using an R1B response for a command.
*) A command with an R1B response should be prepared by calling mmc_prepare_busy_cmd(), which make us respects the host's busy timeout constraints. **) When an R1B response is being used and the host also supports HW busy detection, we should skip to poll for busy completion.
Suggested-by: Christian Loehle <cloehle@hyperstone.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Christian Loehle <cloehle@hyperstone.com> Link: https://lore.kernel.org/r/20230213133707.27857-1-ulf.hansson@linaro.org
show more ...
|
Revision tags: v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41 |
|
#
e949dee3 |
| 17-May-2022 |
Ulf Hansson <ulf.hansson@linaro.org> |
mmc: core: Fix busy polling for MMC_SEND_OP_COND again
It turned out that polling period for MMC_SEND_OP_COND, that currently is set to 1ms, still isn't sufficient. In particular a Micron eMMC on a
mmc: core: Fix busy polling for MMC_SEND_OP_COND again
It turned out that polling period for MMC_SEND_OP_COND, that currently is set to 1ms, still isn't sufficient. In particular a Micron eMMC on a Beaglebone platform, is reported to sometimes fail to initialize.
Additional test, shows that extending the period to 4ms is working fine, so let's make that change.
Reported-by: Jean Rene Dawin <jdawin@math.uni-bielefeld.de> Tested-by: Jean Rene Dawin <jdawin@math.uni-bielefeld.de> Fixes: 1760fdb6fe9f (mmc: core: Restore (almost) the busy polling for MMC_SEND_OP_COND") Fixes: 76bfc7ccc2fa ("mmc: core: adjust polling interval for CMD1") Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://lore.kernel.org/r/20220517101046.27512-1-ulf.hansson@linaro.org
show more ...
|
Revision tags: v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27 |
|
#
1760fdb6 |
| 04-Mar-2022 |
Ulf Hansson <ulf.hansson@linaro.org> |
mmc: core: Restore (almost) the busy polling for MMC_SEND_OP_COND
Commit 76bfc7ccc2fa ("mmc: core: adjust polling interval for CMD1"), significantly decreased the polling period from ~10-12ms into j
mmc: core: Restore (almost) the busy polling for MMC_SEND_OP_COND
Commit 76bfc7ccc2fa ("mmc: core: adjust polling interval for CMD1"), significantly decreased the polling period from ~10-12ms into just a couple of us. The purpose was to decrease the total time spent in the busy polling loop, but unfortunate it has lead to problems, that causes eMMC cards to never gets out busy and thus fails to be initialized.
To fix the problem, but also to try to keep some of the new improved behaviour, let's start by using a polling period of 1-2ms, which then increases for each loop, according to common polling loop in __mmc_poll_for_busy().
Reported-by: Jean Rene Dawin <jdawin@math.uni-bielefeld.de> Reported-by: H. Nikolaus Schaller <hns@goldelico.com> Cc: Huijin Park <huijin.park@samsung.com> Fixes: 76bfc7ccc2fa ("mmc: core: adjust polling interval for CMD1") Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Tested-by: Jean Rene Dawin <jdawin@math.uni-bielefeld.de> Tested-by: H. Nikolaus Schaller <hns@goldelico.com> Link: https://lore.kernel.org/r/20220304105656.149281-1-ulf.hansson@linaro.org
show more ...
|
Revision tags: v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1 |
|
#
76bfc7cc |
| 04-Nov-2021 |
Huijin Park <huijin.park@samsung.com> |
mmc: core: adjust polling interval for CMD1
In mmc_send_op_cond(), loops are continuously performed at the same interval of 10 ms. However the behaviour is not good for some eMMC which can be out f
mmc: core: adjust polling interval for CMD1
In mmc_send_op_cond(), loops are continuously performed at the same interval of 10 ms. However the behaviour is not good for some eMMC which can be out from a busy state earlier than 10 ms if normal.
Rather than fixing about the interval time in mmc_send_op_cond(), let's instead convert into using the common __mmc_poll_for_busy().
The reason for adjusting the interval time is that it is important to reduce the eMMC initialization time, especially in devices that use eMMC as rootfs.
Test log(eMMC:KLM8G1GETF-B041):
before: 12 ms (0.311016 - 0.298729) [ 0.295823] mmc0: starting CMD0 arg 00000000 flags 000000c0 [ 0.298729] mmc0: starting CMD1 arg 40000080 flags 000000e1<-start [ 0.311016] mmc0: starting CMD1 arg 40000080 flags 000000e1<-finish [ 0.311336] mmc0: starting CMD2 arg 00000000 flags 00000007
after: 2 ms (0.301270 - 0.298762) [ 0.295862] mmc0: starting CMD0 arg 00000000 flags 000000c0 [ 0.298762] mmc0: starting CMD1 arg 40000080 flags 000000e1<-start [ 0.299067] mmc0: starting CMD1 arg 40000080 flags 000000e1 [ 0.299441] mmc0: starting CMD1 arg 40000080 flags 000000e1 [ 0.299879] mmc0: starting CMD1 arg 40000080 flags 000000e1 [ 0.300446] mmc0: starting CMD1 arg 40000080 flags 000000e1 [ 0.301270] mmc0: starting CMD1 arg 40000080 flags 000000e1<-finish [ 0.301572] mmc0: starting CMD2 arg 00000000 flags 00000007
Signed-off-by: Huijin Park <huijin.park@samsung.com> Link: https://lore.kernel.org/r/20211104063231.2115-3-huijin.park@samsung.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
#
2ebbdace |
| 04-Nov-2021 |
Huijin Park <huijin.park@samsung.com> |
mmc: core: change __mmc_poll_for_busy() parameter type
This patch changes the __mmc_poll_for_busy() first parameter type from 'struct mmc_card*' to 'struct mmc_host*'. Because the function refers on
mmc: core: change __mmc_poll_for_busy() parameter type
This patch changes the __mmc_poll_for_busy() first parameter type from 'struct mmc_card*' to 'struct mmc_host*'. Because the function refers only 'struct mmc_host' to get hostname.
Signed-off-by: Huijin Park <huijin.park@samsung.com> Link: https://lore.kernel.org/r/20211104063231.2115-2-huijin.park@samsung.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60 |
|
#
fe72d08a |
| 17-Aug-2021 |
Bean Huo <beanhuo@micron.com> |
mmc: core: Issue HPI in case the BKOPS timed out
If the BKOPS timed out, the card is probably still busy in the R1_STATE_PRG. Rather than continue as nothing has happened and hitting and error for t
mmc: core: Issue HPI in case the BKOPS timed out
If the BKOPS timed out, the card is probably still busy in the R1_STATE_PRG. Rather than continue as nothing has happened and hitting and error for the next command being sent, let's try to abort the running BKOPS by sending a HPI command to get back into R1_STATE_TRAN.
Signed-off-by: Bean Huo <beanhuo@micron.com> Link: https://lore.kernel.org/r/20210817224208.153652-2-huobean@gmail.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49 |
|
#
6966e609 |
| 02-Jul-2021 |
Ulf Hansson <ulf.hansson@linaro.org> |
mmc: core: Avoid hogging the CPU while polling for busy after I/O writes
When mmc_blk_card_busy() calls card_busy_detect() to poll for the card's state with CMD13, this is done without any delays in
mmc: core: Avoid hogging the CPU while polling for busy after I/O writes
When mmc_blk_card_busy() calls card_busy_detect() to poll for the card's state with CMD13, this is done without any delays in between the commands being sent.
Rather than fixing card_busy_detect() in this regards, let's instead convert into using the common __mmc_poll_for_busy(), which also helps us to avoid open-coding.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Link: https://lore.kernel.org/r/20210702134229.357717-4-ulf.hansson@linaro.org
show more ...
|
#
972d5084 |
| 02-Jul-2021 |
Ulf Hansson <ulf.hansson@linaro.org> |
mmc: core: Avoid hogging the CPU while polling for busy in the I/O err path
When mmc_blk_fix_state() sends a CMD12 to try to move the card into the transfer state, it calls card_busy_detect() to pol
mmc: core: Avoid hogging the CPU while polling for busy in the I/O err path
When mmc_blk_fix_state() sends a CMD12 to try to move the card into the transfer state, it calls card_busy_detect() to poll for the card's state with CMD13. This is done without any delays in between the commands being sent.
Rather than fixing card_busy_detect() in this regards, let's instead convert into using the common mmc_poll_for_busy(), which also helps us to avoid open-coding.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Link: https://lore.kernel.org/r/20210702134229.357717-2-ulf.hansson@linaro.org
show more ...
|
Revision tags: v5.13, v5.10.46, v5.10.43 |
|
#
21adc2e4 |
| 08-Jun-2021 |
Wolfram Sang <wsa+renesas@sang-engineering.com> |
mmc: Improve function name when aborting a tuning cmd
'mmc_abort_tuning()' made me think tuning gets completely aborted. However, it sends only a STOP cmd to cancel the current tuning cmd. Tuning pr
mmc: Improve function name when aborting a tuning cmd
'mmc_abort_tuning()' made me think tuning gets completely aborted. However, it sends only a STOP cmd to cancel the current tuning cmd. Tuning process may still continue after that. So, rename the function to 'mmc_send_abort_tuning()' to better reflect all this.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Link: https://lore.kernel.org/r/20210608180620.40059-1-wsa+renesas@sang-engineering.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36 |
|
#
130206a6 |
| 11-May-2021 |
Ulf Hansson <ulf.hansson@linaro.org> |
mmc: core: Add support for cache ctrl for SD cards
In SD spec v6.x the SD function extension registers for performance enhancements were introduced. As a part of this an optional internal cache on t
mmc: core: Add support for cache ctrl for SD cards
In SD spec v6.x the SD function extension registers for performance enhancements were introduced. As a part of this an optional internal cache on the SD card, can be used to improve performance.
The let the SD card use the cache, the host needs to enable it and manage flushing of the cache, so let's add support for this.
Note that for an SD card supporting the cache it's mandatory for it, to also support the poweroff notification feature. According to the SD spec, if the cache has been enabled and a poweroff notification is sent to the card, that implicitly also means that the card should flush its internal cache. Therefore, dealing with cache flushing for REQ_OP_FLUSH block requests is sufficient.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Avri Altman <avri.altman@wdc.com> Link: https://lore.kernel.org/r/20210511101359.83521-1-ulf.hansson@linaro.org
show more ...
|
Revision tags: v5.10.35 |
|
#
8ae11ede |
| 06-May-2021 |
Ulf Hansson <ulf.hansson@linaro.org> |
mmc: core: Move eMMC cache flushing to a new bus_ops callback
To prepare to add internal cache management for SD cards, let's start by moving the eMMC specific code into a new ->flush_cache() bus_op
mmc: core: Move eMMC cache flushing to a new bus_ops callback
To prepare to add internal cache management for SD cards, let's start by moving the eMMC specific code into a new ->flush_cache() bus_ops callback.
In this way, it becomes straight forward to add the SD specific parts, as subsequent changes are about to show.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Avri Altman <avri.altman@wdc.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20210506145829.198823-2-ulf.hansson@linaro.org
show more ...
|
#
cec18ad9 |
| 04-May-2021 |
Ulf Hansson <ulf.hansson@linaro.org> |
mmc: core: Prepare mmc_send_cxd_data() to be re-used for additional cmds
The function mmc_send_cxd_data() sends a data read command of ADTC type and prepares to receive an R1 response. To make it ev
mmc: core: Prepare mmc_send_cxd_data() to be re-used for additional cmds
The function mmc_send_cxd_data() sends a data read command of ADTC type and prepares to receive an R1 response. To make it even more re-usable, let's extend it with another in-parameter for the command argument. While at it, let's also rename the function to mmc_send_adtc_data() as it better describes its purpose.
Note that, this change doesn't add any new users of the function. Instead that is done from subsequent changes.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Acked-by: Avri Altman <avri.altman@wdc.com> Link: https://lore.kernel.org/r/20210504161222.101536-7-ulf.hansson@linaro.org
show more ...
|
#
04f967ad |
| 04-May-2021 |
Ulf Hansson <ulf.hansson@linaro.org> |
mmc: core: Extend re-use of __mmc_poll_for_busy()
Via __mmc_poll_for_busy() we end up polling with the ->card_busy() host ops or by sending the CMD13. To allow polling of different types, which is n
mmc: core: Extend re-use of __mmc_poll_for_busy()
Via __mmc_poll_for_busy() we end up polling with the ->card_busy() host ops or by sending the CMD13. To allow polling of different types, which is needed to support a few new SD card features, let's rework the code around __mmc_poll_for_busy() to make it more generic.
More precisely, let __mmc_poll_for_busy() take a pointer to a callback function as in-parameter, which it calls to poll for busy state completion. Additionally, let's share __mmc_poll_for_busy() to allow it to be re-used outside of mmc_ops.c. Subsequent changes will make use of it.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Acked-by: Avri Altman <avri.altman@wdc.com> Link: https://lore.kernel.org/r/20210504161222.101536-5-ulf.hansson@linaro.org
show more ...
|
#
1e0b069b |
| 04-May-2021 |
Ulf Hansson <ulf.hansson@linaro.org> |
mmc: core: Re-structure some code in __mmc_poll_for_busy()
To make the code a bit more understandable, let's move the check about whether polling is allowed or not, out to the caller instead. In thi
mmc: core: Re-structure some code in __mmc_poll_for_busy()
To make the code a bit more understandable, let's move the check about whether polling is allowed or not, out to the caller instead. In this way, we can also drop the send_status in-parameter, so let's do that.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Acked-by: Avri Altman <avri.altman@wdc.com> Link: https://lore.kernel.org/r/20210504161222.101536-4-ulf.hansson@linaro.org
show more ...
|
#
c7bedef0 |
| 04-May-2021 |
Ulf Hansson <ulf.hansson@linaro.org> |
mmc: core: Take into account MMC_CAP_NEED_RSP_BUSY for eMMC HPI commands
In mmc_send_hpi_cmd() the host->max_busy_timeout is being validated towards the timeout for the eMMC HPI command, as to decid
mmc: core: Take into account MMC_CAP_NEED_RSP_BUSY for eMMC HPI commands
In mmc_send_hpi_cmd() the host->max_busy_timeout is being validated towards the timeout for the eMMC HPI command, as to decide whether an R1 or R1B response should be used.
Although, it has turned out the some host can't cope with that conversion, but needs R1B, which means MMC_CAP_NEED_RSP_BUSY is set for them. Let's take this into account, via using the common mmc_prepare_busy_cmd() when doing the validation, which also avoids some open coding.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Acked-by: Avri Altman <avri.altman@wdc.com> Link: https://lore.kernel.org/r/20210504161222.101536-3-ulf.hansson@linaro.org
show more ...
|
#
e62f1e0b |
| 04-May-2021 |
Ulf Hansson <ulf.hansson@linaro.org> |
mmc: core: Drop open coding when preparing commands with busy signaling
Similar code for validating the host->max_busy_timeout towards the current command's busy timeout, exists in mmc_do_erase(), m
mmc: core: Drop open coding when preparing commands with busy signaling
Similar code for validating the host->max_busy_timeout towards the current command's busy timeout, exists in mmc_do_erase(), mmc_sleep() and __mmc_switch(). Let's move the common code into a helper function.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Acked-by: Avri Altman <avri.altman@wdc.com> Link: https://lore.kernel.org/r/20210504161222.101536-2-ulf.hansson@linaro.org
show more ...
|
Revision tags: v5.10.34, v5.4.116, v5.10.33, v5.12 |
|
#
97fce126 |
| 25-Apr-2021 |
Avri Altman <avri.altman@wdc.com> |
mmc: block: Issue a cache flush only when it's enabled
In command queueing mode, the cache isn't flushed via the mmc_flush_cache() function, but instead by issuing a CMDQ_TASK_MGMT (CMD48) with a FL
mmc: block: Issue a cache flush only when it's enabled
In command queueing mode, the cache isn't flushed via the mmc_flush_cache() function, but instead by issuing a CMDQ_TASK_MGMT (CMD48) with a FLUSH_CACHE opcode. In this path, we need to check if cache has been enabled, before deciding to flush the cache, along the lines of what's being done in mmc_flush_cache().
To fix this problem, let's add a new bus ops callback ->cache_enabled() and implement it for the mmc bus type. In this way, the mmc block device driver can call it to know whether cache flushing should be done.
Fixes: 1e8e55b67030 (mmc: block: Add CQE support) Cc: stable@vger.kernel.org Reported-by: Brendan Peter <bpeter@lytx.com> Signed-off-by: Avri Altman <avri.altman@wdc.com> Tested-by: Brendan Peter <bpeter@lytx.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20210425060207.2591-2-avri.altman@wdc.com Link: https://lore.kernel.org/r/20210425060207.2591-3-avri.altman@wdc.com [Ulf: Squashed the two patches and made some minor updates] Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: v5.10.32, v5.10.31 |
|
#
5b96247c |
| 14-Apr-2021 |
Bean Huo <beanhuo@micron.com> |
mmc: core: Let eMMC sanitize not retry in case of timeout/failure
Not all commands need to be retried in case of a timeout/failure. This is the case for the eMMC sanitize command, for example, which
mmc: core: Let eMMC sanitize not retry in case of timeout/failure
Not all commands need to be retried in case of a timeout/failure. This is the case for the eMMC sanitize command, for example, which is issued through the ioctl interface. More precisely, in case of timeout, retrying could make the user wait for a very long time as each retry loop could last for a couple of minutes.
Therefore, let's not use retries for the eMMC sanitize command.
Signed-off-by: Bean Huo <beanhuo@micron.com> Link: https://lore.kernel.org/r/20210414212236.346813-3-huobean@gmail.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
#
5e52a168 |
| 14-Apr-2021 |
Bean Huo <beanhuo@micron.com> |
mmc: core: Add a retries parameter to __mmc_switch function
Add command retries parameter to __mmc_switch(), let caller pass retries according to the caller's condition.
Signed-off-by: Bean Huo <be
mmc: core: Add a retries parameter to __mmc_switch function
Add command retries parameter to __mmc_switch(), let caller pass retries according to the caller's condition.
Signed-off-by: Bean Huo <beanhuo@micron.com> Link: https://lore.kernel.org/r/20210414212236.346813-2-huobean@gmail.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: v5.10.30 |
|
#
4f111d04 |
| 02-Apr-2021 |
Bean Huo <beanhuo@micron.com> |
mmc: core: Use userland specified timeout value for eMMC sanitize
As the density increases, the 4-minute timeout value for sanitize is no longer feasible. At the same time, devices of different dens
mmc: core: Use userland specified timeout value for eMMC sanitize
As the density increases, the 4-minute timeout value for sanitize is no longer feasible. At the same time, devices of different densities have different timeout values, which makes it difficult to use a common timeout value. Therefore, let's pass down the userland-specified sanitize timeout value so it can be used.
Signed-off-by: Bean Huo <beanhuo@micron.com> Link: https://lore.kernel.org/r/20210402092432.25069-2-huobean@gmail.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17 |
|
#
b53f0bee |
| 14-Feb-2021 |
Yue Hu <huyue2@yulong.com> |
mmc: core: Reduce code duplication to mmc_spi_send_{csd|cid}
mmc_spi_send_{csd|cid} have similar function body. Let's remove the duplicated part to simplify the code, just add opcode to distinguish
mmc: core: Reduce code duplication to mmc_spi_send_{csd|cid}
mmc_spi_send_{csd|cid} have similar function body. Let's remove the duplicated part to simplify the code, just add opcode to distinguish them in changed mmc_spi_send_cxd().
Signed-off-by: Yue Hu <huyue2@yulong.com> Link: https://lore.kernel.org/r/20210215015116.1355-1-zbestahu@gmail.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: v5.11, v5.10.16, v5.10.15, v5.10.14 |
|
#
9dbd1ddf |
| 31-Jan-2021 |
Yue Hu <huyue2@yulong.com> |
mmc: core: Use host instead of card argument to mmc_spi_send_csd()
Since mmc_send_cxd_data() does not care card if opcode is MMC_SEND_CSD.
Signed-off-by: Yue Hu <huyue2@yulong.com> Link: https://lo
mmc: core: Use host instead of card argument to mmc_spi_send_csd()
Since mmc_send_cxd_data() does not care card if opcode is MMC_SEND_CSD.
Signed-off-by: Yue Hu <huyue2@yulong.com> Link: https://lore.kernel.org/r/20210201055507.542-1-zbestahu@gmail.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
#
20d6f231 |
| 25-Apr-2021 |
Avri Altman <avri.altman@wdc.com> |
mmc: block: Issue a cache flush only when it's enabled
commit 97fce126e279690105ee15be652b465fd96f9997 upstream.
In command queueing mode, the cache isn't flushed via the mmc_flush_cache() function
mmc: block: Issue a cache flush only when it's enabled
commit 97fce126e279690105ee15be652b465fd96f9997 upstream.
In command queueing mode, the cache isn't flushed via the mmc_flush_cache() function, but instead by issuing a CMDQ_TASK_MGMT (CMD48) with a FLUSH_CACHE opcode. In this path, we need to check if cache has been enabled, before deciding to flush the cache, along the lines of what's being done in mmc_flush_cache().
To fix this problem, let's add a new bus ops callback ->cache_enabled() and implement it for the mmc bus type. In this way, the mmc block device driver can call it to know whether cache flushing should be done.
Fixes: 1e8e55b67030 (mmc: block: Add CQE support) Cc: stable@vger.kernel.org Reported-by: Brendan Peter <bpeter@lytx.com> Signed-off-by: Avri Altman <avri.altman@wdc.com> Tested-by: Brendan Peter <bpeter@lytx.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20210425060207.2591-2-avri.altman@wdc.com Link: https://lore.kernel.org/r/20210425060207.2591-3-avri.altman@wdc.com [Ulf: Squashed the two patches and made some minor updates] Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.10, v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43, v5.4.42, v5.4.41, v5.4.40, v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34, v5.4.33, v5.4.32, v5.4.31 |
|
#
44aebc16 |
| 02-Apr-2020 |
Jason Yan <yanaijie@huawei.com> |
mmc: core: make mmc_interrupt_hpi() static
Fix the following sparse warning:
drivers/mmc/core/mmc_ops.c:881:5: warning: symbol 'mmc_interrupt_hpi' was not declared. Should it be static?
Reported-b
mmc: core: make mmc_interrupt_hpi() static
Fix the following sparse warning:
drivers/mmc/core/mmc_ops.c:881:5: warning: symbol 'mmc_interrupt_hpi' was not declared. Should it be static?
Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Jason Yan <yanaijie@huawei.com> Fixes: 55c2b8b9a383 ("mmc: core: Re-work the code for eMMC sanitize") Link: https://lore.kernel.org/r/20200403034727.11879-1-yanaijie@huawei.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: v5.4.30, v5.4.29, v5.6, v5.4.28, v5.4.27, v5.4.26 |
|
#
55c2b8b9 |
| 16-Mar-2020 |
Ulf Hansson <ulf.hansson@linaro.org> |
mmc: core: Re-work the code for eMMC sanitize
The error path for sanitize operations that completes with -ETIMEDOUT, is tightly coupled with the internal request handling code of the core. More prec
mmc: core: Re-work the code for eMMC sanitize
The error path for sanitize operations that completes with -ETIMEDOUT, is tightly coupled with the internal request handling code of the core. More precisely, mmc_wait_for_req_done() checks for specific sanitize errors. This is not only inefficient as it affects all types of requests, but also hackish.
Therefore, let's improve the behaviour by moving the error path out of the mmc core. To do that, retuning needs to be held while running the sanitize operation.
Moreover, to avoid exporting unnecessary symbols to the mmc block module, let's move the code into the mmc_ops.c file. While updating the actual code, let's also take the opportunity to clean up some of the mess around it.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://lore.kernel.org/r/20200316152152.15122-1-ulf.hansson@linaro.org
show more ...
|