2019-06-04 16:11:33 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
2005-04-17 06:20:36 +08:00
|
|
|
/*
|
2007-02-28 22:33:10 +08:00
|
|
|
* linux/drivers/mmc/core/core.c
|
2005-04-17 06:20:36 +08:00
|
|
|
*
|
|
|
|
* Copyright (C) 2003-2004 Russell King, All Rights Reserved.
|
2005-09-07 06:18:56 +08:00
|
|
|
* SD support Copyright (C) 2004 Ian Molton, All Rights Reserved.
|
2008-06-28 18:52:45 +08:00
|
|
|
* Copyright (C) 2005-2008 Pierre Ossman, All Rights Reserved.
|
2006-10-21 18:35:02 +08:00
|
|
|
* MMCv4 support Copyright (C) 2006 Philip Langdale, All Rights Reserved.
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/interrupt.h>
|
|
|
|
#include <linux/completion.h>
|
|
|
|
#include <linux/device.h>
|
|
|
|
#include <linux/delay.h>
|
|
|
|
#include <linux/pagemap.h>
|
|
|
|
#include <linux/err.h>
|
2007-09-24 13:15:48 +08:00
|
|
|
#include <linux/leds.h>
|
2005-09-07 06:18:53 +08:00
|
|
|
#include <linux/scatterlist.h>
|
2008-11-27 03:54:17 +08:00
|
|
|
#include <linux/log2.h>
|
2010-11-28 13:21:30 +08:00
|
|
|
#include <linux/pm_runtime.h>
|
2013-09-20 17:02:35 +08:00
|
|
|
#include <linux/pm_wakeup.h>
|
2011-07-26 08:13:11 +08:00
|
|
|
#include <linux/suspend.h>
|
2011-08-19 20:52:37 +08:00
|
|
|
#include <linux/fault-inject.h>
|
|
|
|
#include <linux/random.h>
|
2012-09-17 16:42:02 +08:00
|
|
|
#include <linux/slab.h>
|
2013-08-26 09:19:22 +08:00
|
|
|
#include <linux/of.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
#include <linux/mmc/card.h>
|
|
|
|
#include <linux/mmc/host.h>
|
2006-12-25 05:46:55 +08:00
|
|
|
#include <linux/mmc/mmc.h>
|
|
|
|
#include <linux/mmc/sd.h>
|
2014-03-10 21:02:41 +08:00
|
|
|
#include <linux/mmc/slot-gpio.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2016-03-31 11:16:27 +08:00
|
|
|
#define CREATE_TRACE_POINTS
|
|
|
|
#include <trace/events/mmc.h>
|
|
|
|
|
2007-02-28 22:33:10 +08:00
|
|
|
#include "core.h"
|
2017-01-13 21:14:14 +08:00
|
|
|
#include "card.h"
|
2007-05-19 20:32:22 +08:00
|
|
|
#include "bus.h"
|
|
|
|
#include "host.h"
|
2007-05-26 19:48:18 +08:00
|
|
|
#include "sdio_bus.h"
|
2014-11-28 21:38:36 +08:00
|
|
|
#include "pwrseq.h"
|
2006-12-25 05:46:55 +08:00
|
|
|
|
|
|
|
#include "mmc_ops.h"
|
|
|
|
#include "sd_ops.h"
|
2007-05-22 02:23:20 +08:00
|
|
|
#include "sdio_ops.h"
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2016-07-27 06:04:03 +08:00
|
|
|
/* The max erase timeout, used when host->max_busy_timeout isn't specified */
|
|
|
|
#define MMC_ERASE_TIMEOUT_MS (60 * 1000) /* 60 s */
|
2019-02-26 23:10:25 +08:00
|
|
|
#define SD_DISCARD_TIMEOUT_MS (250)
|
2016-07-27 06:04:03 +08:00
|
|
|
|
2012-05-09 22:15:26 +08:00
|
|
|
static const unsigned freqs[] = { 400000, 300000, 200000, 100000 };
|
2007-05-19 20:32:22 +08:00
|
|
|
|
MMC core learns about SPI
Teach the MMC/SD/SDIO core about using SPI mode.
- Use mmc_host_is_spi() so enumeration works through SPI signaling
and protocols, not just the native versions.
- Provide the SPI response type flags with each request issued,
including requests from the new lock/unlock code.
- Understand that cmd->resp[0] and mmc_get_status() results for SPI
return different values than for "native" MMC/SD protocol; this
affects resetting, checking card lock status, and some others.
- Understand that some commands act a bit differently ... notably:
* OP_COND command doesn't return the OCR
* APP_CMD status doesn't have an R1_APP_CMD analogue
Those changes required some new and updated primitives:
- Provide utilities to access two SPI-only requests, and one
request that wasn't previously needed:
* mmc_spi_read_ocr() ... SPI only
* mmc_spi_set_crc() ... SPI only (override by module parm)
* mmc_send_cid() ... for use without broadcast mode
- Updated internal routines:
* Previous mmc_send_csd() modified into mmc_send_cxd_native();
it uses native "R2" responses, which include 16 bytes of data.
* Previous mmc_send_ext_csd() becomes new mmc_send_cxd_data()
helper for command-and-data access
* Bugfix to that mmc_send_cxd_data() code: dma-to-stack is
unsafe/nonportable, so kmalloc a bounce buffer instead.
- Modified mmc_send_ext_csd() now uses mmc_send_cxd_data() helper
- Modified mmc_send_csd(), and new mmc_spi_send_cid(), routines use
those helper routines based on whether they're native or SPI
The newest categories of cards supported by the MMC stack aren't expected
to work yet with SPI: MMC or SD cards with over 4GB data, and SDIO.
All those cards support SPI mode, so eventually they should work too.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
2007-08-09 00:11:32 +08:00
|
|
|
/*
|
|
|
|
* Enabling software CRCs on the data blocks can be a significant (30%)
|
|
|
|
* performance cost, and for other reasons may not always be desired.
|
|
|
|
* So we allow it it to be disabled.
|
|
|
|
*/
|
2012-01-13 07:02:20 +08:00
|
|
|
bool use_spi_crc = 1;
|
MMC core learns about SPI
Teach the MMC/SD/SDIO core about using SPI mode.
- Use mmc_host_is_spi() so enumeration works through SPI signaling
and protocols, not just the native versions.
- Provide the SPI response type flags with each request issued,
including requests from the new lock/unlock code.
- Understand that cmd->resp[0] and mmc_get_status() results for SPI
return different values than for "native" MMC/SD protocol; this
affects resetting, checking card lock status, and some others.
- Understand that some commands act a bit differently ... notably:
* OP_COND command doesn't return the OCR
* APP_CMD status doesn't have an R1_APP_CMD analogue
Those changes required some new and updated primitives:
- Provide utilities to access two SPI-only requests, and one
request that wasn't previously needed:
* mmc_spi_read_ocr() ... SPI only
* mmc_spi_set_crc() ... SPI only (override by module parm)
* mmc_send_cid() ... for use without broadcast mode
- Updated internal routines:
* Previous mmc_send_csd() modified into mmc_send_cxd_native();
it uses native "R2" responses, which include 16 bytes of data.
* Previous mmc_send_ext_csd() becomes new mmc_send_cxd_data()
helper for command-and-data access
* Bugfix to that mmc_send_cxd_data() code: dma-to-stack is
unsafe/nonportable, so kmalloc a bounce buffer instead.
- Modified mmc_send_ext_csd() now uses mmc_send_cxd_data() helper
- Modified mmc_send_csd(), and new mmc_spi_send_cid(), routines use
those helper routines based on whether they're native or SPI
The newest categories of cards supported by the MMC stack aren't expected
to work yet with SPI: MMC or SD cards with over 4GB data, and SDIO.
All those cards support SPI mode, so eventually they should work too.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
2007-08-09 00:11:32 +08:00
|
|
|
module_param(use_spi_crc, bool, 0);
|
|
|
|
|
2007-05-19 20:32:22 +08:00
|
|
|
static int mmc_schedule_delayed_work(struct delayed_work *work,
|
|
|
|
unsigned long delay)
|
|
|
|
{
|
mmc: core: Optimize boot time by detecting cards simultaneously
The mmc workqueue is an ordered workqueue, allowing only one work to
execute per given time. As this workqueue is used for card detection, the
conseqeunce is that cards will be detected one by one waiting for each
other.
Moreover, most of the time spent during card initialization is waiting for
the card's internal firmware to be ready. From a CPU perspective this
typically means waiting for a completion variable to be kicked via an
IRQ-handler or waiting for a sleep timer to finish.
This behaviour of detecting/initializing cards is sub-optimal, especially
for SOCs having several controllers/cards.
Let's convert to use the system_freezable_wq for the mmc detect works.
This enables several works to be executed simultaneously and thus also
cards to be detected like so.
Tests on UX500, which holds two eMMC cards and an SD-card (actually also
an SDIO card, currently not detected), shows a significant improved
behaviour due to this change.
Before this change, both the eMMC cards waited for the SD card to be
initialized as its detect work entered the workqueue first. In some cases,
depending on the characteristic of the SD-card, they got delayed 1-1.5 s.
Additionally for the second eMMC, it needed to wait for the first eMMC to
be initialized which added another 120-190 ms.
Converting to the system_freezable_wq, removed these delays and made both
the eMMC cards available far earlier in the boot sequence.
Selecting the system_freezable_wq, in favour of for example the system_wq,
is because we need card detection mechanism to be disabled once userspace
are frozen during system PM. Currently the mmc core deal with this via PM
notifiers, but following patches may utilize the behaviour of the
system_freezable_wq, to simplify the use of the PM notifiers.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Alan Cooper <alcooperx@gmail.com>
Tested-by: Shawn Lin <shawn.lin@rock-chips.com>
2015-12-01 17:35:29 +08:00
|
|
|
/*
|
|
|
|
* We use the system_freezable_wq, because of two reasons.
|
|
|
|
* First, it allows several works (not the same work item) to be
|
|
|
|
* executed simultaneously. Second, the queue becomes frozen when
|
|
|
|
* userspace becomes frozen during system PM.
|
|
|
|
*/
|
|
|
|
return queue_delayed_work(system_freezable_wq, work, delay);
|
2007-05-19 20:32:22 +08:00
|
|
|
}
|
|
|
|
|
2011-08-19 20:52:37 +08:00
|
|
|
#ifdef CONFIG_FAIL_MMC_REQUEST
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Internal function. Inject random data errors.
|
|
|
|
* If mmc_data is NULL no errors are injected.
|
|
|
|
*/
|
|
|
|
static void mmc_should_fail_request(struct mmc_host *host,
|
|
|
|
struct mmc_request *mrq)
|
|
|
|
{
|
|
|
|
struct mmc_command *cmd = mrq->cmd;
|
|
|
|
struct mmc_data *data = mrq->data;
|
|
|
|
static const int data_errors[] = {
|
|
|
|
-ETIMEDOUT,
|
|
|
|
-EILSEQ,
|
|
|
|
-EIO,
|
|
|
|
};
|
|
|
|
|
|
|
|
if (!data)
|
|
|
|
return;
|
|
|
|
|
2019-02-22 21:51:34 +08:00
|
|
|
if ((cmd && cmd->error) || data->error ||
|
2011-08-19 20:52:37 +08:00
|
|
|
!should_fail(&host->fail_mmc_request, data->blksz * data->blocks))
|
|
|
|
return;
|
|
|
|
|
2013-04-30 07:21:31 +08:00
|
|
|
data->error = data_errors[prandom_u32() % ARRAY_SIZE(data_errors)];
|
|
|
|
data->bytes_xfered = (prandom_u32() % (data->bytes_xfered >> 9)) << 9;
|
2011-08-19 20:52:37 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
#else /* CONFIG_FAIL_MMC_REQUEST */
|
|
|
|
|
|
|
|
static inline void mmc_should_fail_request(struct mmc_host *host,
|
|
|
|
struct mmc_request *mrq)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
#endif /* CONFIG_FAIL_MMC_REQUEST */
|
|
|
|
|
mmc: core: Add support for sending commands during data transfer
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 <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-08-16 18:44:11 +08:00
|
|
|
static inline void mmc_complete_cmd(struct mmc_request *mrq)
|
|
|
|
{
|
|
|
|
if (mrq->cap_cmd_during_tfr && !completion_done(&mrq->cmd_completion))
|
|
|
|
complete_all(&mrq->cmd_completion);
|
|
|
|
}
|
|
|
|
|
|
|
|
void mmc_command_done(struct mmc_host *host, struct mmc_request *mrq)
|
|
|
|
{
|
|
|
|
if (!mrq->cap_cmd_during_tfr)
|
|
|
|
return;
|
|
|
|
|
|
|
|
mmc_complete_cmd(mrq);
|
|
|
|
|
|
|
|
pr_debug("%s: cmd done, tfr ongoing (CMD%u)\n",
|
|
|
|
mmc_hostname(host), mrq->cmd->opcode);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(mmc_command_done);
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/**
|
2006-05-04 20:51:45 +08:00
|
|
|
* mmc_request_done - finish processing an MMC request
|
|
|
|
* @host: MMC host which completed request
|
|
|
|
* @mrq: MMC request which request
|
2005-04-17 06:20:36 +08:00
|
|
|
*
|
|
|
|
* MMC drivers should call this function when they have completed
|
2006-05-04 20:51:45 +08:00
|
|
|
* their processing of a request.
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
|
|
|
void mmc_request_done(struct mmc_host *host, struct mmc_request *mrq)
|
|
|
|
{
|
|
|
|
struct mmc_command *cmd = mrq->cmd;
|
2006-05-05 01:22:51 +08:00
|
|
|
int err = cmd->error;
|
|
|
|
|
2015-05-07 18:10:22 +08:00
|
|
|
/* Flag re-tuning needed on CRC errors */
|
2019-06-18 01:56:50 +08:00
|
|
|
if (cmd->opcode != MMC_SEND_TUNING_BLOCK &&
|
|
|
|
cmd->opcode != MMC_SEND_TUNING_BLOCK_HS200 &&
|
|
|
|
!host->retune_crc_disable &&
|
2015-09-30 17:37:18 +08:00
|
|
|
(err == -EILSEQ || (mrq->sbc && mrq->sbc->error == -EILSEQ) ||
|
2015-05-07 18:10:22 +08:00
|
|
|
(mrq->data && mrq->data->error == -EILSEQ) ||
|
2015-09-30 17:37:18 +08:00
|
|
|
(mrq->stop && mrq->stop->error == -EILSEQ)))
|
2015-05-07 18:10:22 +08:00
|
|
|
mmc_retune_needed(host);
|
|
|
|
|
MMC core learns about SPI
Teach the MMC/SD/SDIO core about using SPI mode.
- Use mmc_host_is_spi() so enumeration works through SPI signaling
and protocols, not just the native versions.
- Provide the SPI response type flags with each request issued,
including requests from the new lock/unlock code.
- Understand that cmd->resp[0] and mmc_get_status() results for SPI
return different values than for "native" MMC/SD protocol; this
affects resetting, checking card lock status, and some others.
- Understand that some commands act a bit differently ... notably:
* OP_COND command doesn't return the OCR
* APP_CMD status doesn't have an R1_APP_CMD analogue
Those changes required some new and updated primitives:
- Provide utilities to access two SPI-only requests, and one
request that wasn't previously needed:
* mmc_spi_read_ocr() ... SPI only
* mmc_spi_set_crc() ... SPI only (override by module parm)
* mmc_send_cid() ... for use without broadcast mode
- Updated internal routines:
* Previous mmc_send_csd() modified into mmc_send_cxd_native();
it uses native "R2" responses, which include 16 bytes of data.
* Previous mmc_send_ext_csd() becomes new mmc_send_cxd_data()
helper for command-and-data access
* Bugfix to that mmc_send_cxd_data() code: dma-to-stack is
unsafe/nonportable, so kmalloc a bounce buffer instead.
- Modified mmc_send_ext_csd() now uses mmc_send_cxd_data() helper
- Modified mmc_send_csd(), and new mmc_spi_send_cid(), routines use
those helper routines based on whether they're native or SPI
The newest categories of cards supported by the MMC stack aren't expected
to work yet with SPI: MMC or SD cards with over 4GB data, and SDIO.
All those cards support SPI mode, so eventually they should work too.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
2007-08-09 00:11:32 +08:00
|
|
|
if (err && cmd->retries && mmc_host_is_spi(host)) {
|
|
|
|
if (cmd->resp[0] & R1_SPI_ILLEGAL_COMMAND)
|
|
|
|
cmd->retries = 0;
|
|
|
|
}
|
|
|
|
|
mmc: core: Add support for sending commands during data transfer
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 <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-08-16 18:44:11 +08:00
|
|
|
if (host->ongoing_mrq == mrq)
|
|
|
|
host->ongoing_mrq = NULL;
|
|
|
|
|
|
|
|
mmc_complete_cmd(mrq);
|
|
|
|
|
2016-03-31 11:16:27 +08:00
|
|
|
trace_mmc_request_done(host, mrq);
|
|
|
|
|
2017-03-28 16:40:31 +08:00
|
|
|
/*
|
|
|
|
* We list various conditions for the command to be considered
|
|
|
|
* properly done:
|
|
|
|
*
|
|
|
|
* - There was no error, OK fine then
|
|
|
|
* - We are not doing some kind of retry
|
|
|
|
* - The card was removed (...so just complete everything no matter
|
|
|
|
* if there are errors or retries)
|
|
|
|
*/
|
|
|
|
if (!err || !cmd->retries || mmc_card_removed(host->card)) {
|
2011-08-19 20:52:37 +08:00
|
|
|
mmc_should_fail_request(host, mrq);
|
|
|
|
|
mmc: core: Add support for sending commands during data transfer
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 <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-08-16 18:44:11 +08:00
|
|
|
if (!host->ongoing_mrq)
|
|
|
|
led_trigger_event(host->led, LED_OFF);
|
2007-09-24 13:15:48 +08:00
|
|
|
|
2014-10-01 20:14:10 +08:00
|
|
|
if (mrq->sbc) {
|
|
|
|
pr_debug("%s: req done <CMD%u>: %d: %08x %08x %08x %08x\n",
|
|
|
|
mmc_hostname(host), mrq->sbc->opcode,
|
|
|
|
mrq->sbc->error,
|
|
|
|
mrq->sbc->resp[0], mrq->sbc->resp[1],
|
|
|
|
mrq->sbc->resp[2], mrq->sbc->resp[3]);
|
|
|
|
}
|
|
|
|
|
2007-07-25 03:46:49 +08:00
|
|
|
pr_debug("%s: req done (CMD%u): %d: %08x %08x %08x %08x\n",
|
|
|
|
mmc_hostname(host), cmd->opcode, err,
|
|
|
|
cmd->resp[0], cmd->resp[1],
|
|
|
|
cmd->resp[2], cmd->resp[3]);
|
|
|
|
|
|
|
|
if (mrq->data) {
|
|
|
|
pr_debug("%s: %d bytes transferred: %d\n",
|
|
|
|
mmc_hostname(host),
|
|
|
|
mrq->data->bytes_xfered, mrq->data->error);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (mrq->stop) {
|
|
|
|
pr_debug("%s: (CMD%u): %d: %08x %08x %08x %08x\n",
|
|
|
|
mmc_hostname(host), mrq->stop->opcode,
|
|
|
|
mrq->stop->error,
|
|
|
|
mrq->stop->resp[0], mrq->stop->resp[1],
|
|
|
|
mrq->stop->resp[2], mrq->stop->resp[3]);
|
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
2017-03-28 16:40:31 +08:00
|
|
|
/*
|
|
|
|
* Request starter must handle retries - see
|
|
|
|
* mmc_wait_for_req_done().
|
|
|
|
*/
|
|
|
|
if (mrq->done)
|
|
|
|
mrq->done(mrq);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
EXPORT_SYMBOL(mmc_request_done);
|
|
|
|
|
2015-05-07 18:10:14 +08:00
|
|
|
static void __mmc_start_request(struct mmc_host *host, struct mmc_request *mrq)
|
|
|
|
{
|
|
|
|
int err;
|
|
|
|
|
|
|
|
/* Assumes host controller has been runtime resumed by mmc_claim_host */
|
|
|
|
err = mmc_retune(host);
|
|
|
|
if (err) {
|
|
|
|
mrq->cmd->error = err;
|
|
|
|
mmc_request_done(host, mrq);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2015-09-22 23:30:25 +08:00
|
|
|
/*
|
|
|
|
* For sdio rw commands we must wait for card busy otherwise some
|
|
|
|
* sdio devices won't work properly.
|
2017-04-23 17:38:27 +08:00
|
|
|
* And bypass I/O abort, reset and bus suspend operations.
|
2015-09-22 23:30:25 +08:00
|
|
|
*/
|
2017-04-23 17:38:27 +08:00
|
|
|
if (sdio_is_io_busy(mrq->cmd->opcode, mrq->cmd->arg) &&
|
|
|
|
host->ops->card_busy) {
|
2015-09-22 23:30:25 +08:00
|
|
|
int tries = 500; /* Wait aprox 500ms at maximum */
|
|
|
|
|
|
|
|
while (host->ops->card_busy(host) && --tries)
|
|
|
|
mmc_delay(1);
|
|
|
|
|
|
|
|
if (tries == 0) {
|
|
|
|
mrq->cmd->error = -EBUSY;
|
|
|
|
mmc_request_done(host, mrq);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
mmc: core: Add support for sending commands during data transfer
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 <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-08-16 18:44:11 +08:00
|
|
|
if (mrq->cap_cmd_during_tfr) {
|
|
|
|
host->ongoing_mrq = mrq;
|
|
|
|
/*
|
|
|
|
* Retry path could come through here without having waiting on
|
|
|
|
* cmd_completion, so ensure it is reinitialised.
|
|
|
|
*/
|
|
|
|
reinit_completion(&mrq->cmd_completion);
|
|
|
|
}
|
|
|
|
|
2016-03-31 11:16:27 +08:00
|
|
|
trace_mmc_request_start(host, mrq);
|
|
|
|
|
2017-08-10 20:08:09 +08:00
|
|
|
if (host->cqe_on)
|
|
|
|
host->cqe_ops->cqe_off(host);
|
|
|
|
|
2015-05-07 18:10:14 +08:00
|
|
|
host->ops->request(host, mrq);
|
|
|
|
}
|
|
|
|
|
2017-09-22 20:36:52 +08:00
|
|
|
static void mmc_mrq_pr_debug(struct mmc_host *host, struct mmc_request *mrq,
|
|
|
|
bool cqe)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2012-02-07 13:13:10 +08:00
|
|
|
if (mrq->sbc) {
|
|
|
|
pr_debug("<%s: starting CMD%u arg %08x flags %08x>\n",
|
|
|
|
mmc_hostname(host), mrq->sbc->opcode,
|
|
|
|
mrq->sbc->arg, mrq->sbc->flags);
|
|
|
|
}
|
|
|
|
|
2017-03-13 20:36:42 +08:00
|
|
|
if (mrq->cmd) {
|
2017-09-22 20:36:52 +08:00
|
|
|
pr_debug("%s: starting %sCMD%u arg %08x flags %08x\n",
|
|
|
|
mmc_hostname(host), cqe ? "CQE direct " : "",
|
|
|
|
mrq->cmd->opcode, mrq->cmd->arg, mrq->cmd->flags);
|
|
|
|
} else if (cqe) {
|
|
|
|
pr_debug("%s: starting CQE transfer for tag %d blkaddr %u\n",
|
|
|
|
mmc_hostname(host), mrq->tag, mrq->data->blk_addr);
|
2017-03-13 20:36:42 +08:00
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2007-07-25 03:46:49 +08:00
|
|
|
if (mrq->data) {
|
|
|
|
pr_debug("%s: blksz %d blocks %d flags %08x "
|
|
|
|
"tsac %d ms nsac %d\n",
|
|
|
|
mmc_hostname(host), mrq->data->blksz,
|
|
|
|
mrq->data->blocks, mrq->data->flags,
|
2007-08-07 20:06:18 +08:00
|
|
|
mrq->data->timeout_ns / 1000000,
|
2007-07-25 03:46:49 +08:00
|
|
|
mrq->data->timeout_clks);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (mrq->stop) {
|
|
|
|
pr_debug("%s: CMD%u arg %08x flags %08x\n",
|
|
|
|
mmc_hostname(host), mrq->stop->opcode,
|
|
|
|
mrq->stop->arg, mrq->stop->flags);
|
|
|
|
}
|
2017-03-13 20:36:42 +08:00
|
|
|
}
|
|
|
|
|
2017-03-13 20:36:43 +08:00
|
|
|
static int mmc_mrq_prep(struct mmc_host *host, struct mmc_request *mrq)
|
2017-03-13 20:36:42 +08:00
|
|
|
{
|
2017-07-19 15:55:45 +08:00
|
|
|
unsigned int i, sz = 0;
|
2017-03-13 20:36:42 +08:00
|
|
|
struct scatterlist *sg;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2017-03-13 20:36:43 +08:00
|
|
|
if (mrq->cmd) {
|
|
|
|
mrq->cmd->error = 0;
|
|
|
|
mrq->cmd->mrq = mrq;
|
|
|
|
mrq->cmd->data = mrq->data;
|
|
|
|
}
|
2014-10-01 20:14:09 +08:00
|
|
|
if (mrq->sbc) {
|
|
|
|
mrq->sbc->error = 0;
|
|
|
|
mrq->sbc->mrq = mrq;
|
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
if (mrq->data) {
|
2016-11-02 15:26:16 +08:00
|
|
|
if (mrq->data->blksz > host->max_blk_size ||
|
|
|
|
mrq->data->blocks > host->max_blk_count ||
|
|
|
|
mrq->data->blocks * mrq->data->blksz > host->max_req_size)
|
|
|
|
return -EINVAL;
|
2017-07-19 15:55:45 +08:00
|
|
|
|
2008-07-29 07:09:37 +08:00
|
|
|
for_each_sg(mrq->data->sg, sg, mrq->data->sg_len, i)
|
|
|
|
sz += sg->length;
|
2016-11-02 15:26:16 +08:00
|
|
|
if (sz != mrq->data->blocks * mrq->data->blksz)
|
|
|
|
return -EINVAL;
|
2017-07-19 15:55:45 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
mrq->data->error = 0;
|
|
|
|
mrq->data->mrq = mrq;
|
|
|
|
if (mrq->stop) {
|
|
|
|
mrq->data->stop = mrq->stop;
|
|
|
|
mrq->stop->error = 0;
|
|
|
|
mrq->stop->mrq = mrq;
|
|
|
|
}
|
|
|
|
}
|
2017-03-13 20:36:43 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2017-09-22 20:36:59 +08:00
|
|
|
int mmc_start_request(struct mmc_host *host, struct mmc_request *mrq)
|
2017-03-13 20:36:43 +08:00
|
|
|
{
|
|
|
|
int err;
|
|
|
|
|
2017-12-01 20:55:30 +08:00
|
|
|
init_completion(&mrq->cmd_completion);
|
|
|
|
|
2017-03-13 20:36:43 +08:00
|
|
|
mmc_retune_hold(host);
|
|
|
|
|
|
|
|
if (mmc_card_removed(host->card))
|
|
|
|
return -ENOMEDIUM;
|
|
|
|
|
2017-09-22 20:36:52 +08:00
|
|
|
mmc_mrq_pr_debug(host, mrq, false);
|
2017-03-13 20:36:43 +08:00
|
|
|
|
|
|
|
WARN_ON(!host->claimed);
|
|
|
|
|
|
|
|
err = mmc_mrq_prep(host, mrq);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
2011-02-07 02:02:48 +08:00
|
|
|
led_trigger_event(host->led, LED_FULL);
|
2015-05-07 18:10:14 +08:00
|
|
|
__mmc_start_request(host, mrq);
|
2014-12-06 01:41:02 +08:00
|
|
|
|
|
|
|
return 0;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
2017-09-22 20:36:59 +08:00
|
|
|
EXPORT_SYMBOL(mmc_start_request);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
static void mmc_wait_done(struct mmc_request *mrq)
|
|
|
|
{
|
2011-07-02 00:55:22 +08:00
|
|
|
complete(&mrq->completion);
|
|
|
|
}
|
|
|
|
|
mmc: core: Add support for sending commands during data transfer
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 <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-08-16 18:44:11 +08:00
|
|
|
static inline void mmc_wait_ongoing_tfr_cmd(struct mmc_host *host)
|
|
|
|
{
|
|
|
|
struct mmc_request *ongoing_mrq = READ_ONCE(host->ongoing_mrq);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If there is an ongoing transfer, wait for the command line to become
|
|
|
|
* available.
|
|
|
|
*/
|
|
|
|
if (ongoing_mrq && !completion_done(&ongoing_mrq->cmd_completion))
|
|
|
|
wait_for_completion(&ongoing_mrq->cmd_completion);
|
|
|
|
}
|
|
|
|
|
2012-03-05 22:52:43 +08:00
|
|
|
static int __mmc_start_req(struct mmc_host *host, struct mmc_request *mrq)
|
2011-07-02 00:55:22 +08:00
|
|
|
{
|
2014-12-06 01:41:02 +08:00
|
|
|
int err;
|
|
|
|
|
mmc: core: Add support for sending commands during data transfer
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 <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-08-16 18:44:11 +08:00
|
|
|
mmc_wait_ongoing_tfr_cmd(host);
|
|
|
|
|
2011-07-02 00:55:22 +08:00
|
|
|
init_completion(&mrq->completion);
|
|
|
|
mrq->done = mmc_wait_done;
|
2014-12-06 01:41:02 +08:00
|
|
|
|
|
|
|
err = mmc_start_request(host, mrq);
|
|
|
|
if (err) {
|
|
|
|
mrq->cmd->error = err;
|
mmc: core: Add support for sending commands during data transfer
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 <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-08-16 18:44:11 +08:00
|
|
|
mmc_complete_cmd(mrq);
|
2011-11-28 22:22:00 +08:00
|
|
|
complete(&mrq->completion);
|
|
|
|
}
|
2014-12-06 01:41:02 +08:00
|
|
|
|
|
|
|
return err;
|
2011-07-02 00:55:22 +08:00
|
|
|
}
|
|
|
|
|
mmc: core: Add support for sending commands during data transfer
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 <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-08-16 18:44:11 +08:00
|
|
|
void mmc_wait_for_req_done(struct mmc_host *host, struct mmc_request *mrq)
|
2011-07-02 00:55:22 +08:00
|
|
|
{
|
2011-10-03 20:33:33 +08:00
|
|
|
struct mmc_command *cmd;
|
|
|
|
|
|
|
|
while (1) {
|
|
|
|
wait_for_completion(&mrq->completion);
|
|
|
|
|
|
|
|
cmd = mrq->cmd;
|
2013-04-18 20:41:55 +08:00
|
|
|
|
2011-11-28 22:22:00 +08:00
|
|
|
if (!cmd->error || !cmd->retries ||
|
|
|
|
mmc_card_removed(host->card))
|
2011-10-03 20:33:33 +08:00
|
|
|
break;
|
|
|
|
|
2015-05-07 18:10:14 +08:00
|
|
|
mmc_retune_recheck(host);
|
|
|
|
|
2011-10-03 20:33:33 +08:00
|
|
|
pr_debug("%s: req failed (CMD%u): %d, retrying...\n",
|
|
|
|
mmc_hostname(host), cmd->opcode, cmd->error);
|
|
|
|
cmd->retries--;
|
|
|
|
cmd->error = 0;
|
2015-05-07 18:10:14 +08:00
|
|
|
__mmc_start_request(host, mrq);
|
2011-10-03 20:33:33 +08:00
|
|
|
}
|
2015-05-07 18:10:14 +08:00
|
|
|
|
|
|
|
mmc_retune_release(host);
|
2011-07-02 00:55:22 +08:00
|
|
|
}
|
mmc: core: Add support for sending commands during data transfer
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 <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-08-16 18:44:11 +08:00
|
|
|
EXPORT_SYMBOL(mmc_wait_for_req_done);
|
|
|
|
|
2017-09-22 20:36:52 +08:00
|
|
|
/*
|
|
|
|
* mmc_cqe_start_req - Start a CQE request.
|
|
|
|
* @host: MMC host to start the request
|
|
|
|
* @mrq: request to start
|
|
|
|
*
|
|
|
|
* Start the request, re-tuning if needed and it is possible. Returns an error
|
|
|
|
* code if the request fails to start or -EBUSY if CQE is busy.
|
|
|
|
*/
|
|
|
|
int mmc_cqe_start_req(struct mmc_host *host, struct mmc_request *mrq)
|
|
|
|
{
|
|
|
|
int err;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* CQE cannot process re-tuning commands. Caller must hold retuning
|
|
|
|
* while CQE is in use. Re-tuning can happen here only when CQE has no
|
|
|
|
* active requests i.e. this is the first. Note, re-tuning will call
|
|
|
|
* ->cqe_off().
|
|
|
|
*/
|
|
|
|
err = mmc_retune(host);
|
|
|
|
if (err)
|
|
|
|
goto out_err;
|
|
|
|
|
|
|
|
mrq->host = host;
|
|
|
|
|
|
|
|
mmc_mrq_pr_debug(host, mrq, true);
|
|
|
|
|
|
|
|
err = mmc_mrq_prep(host, mrq);
|
|
|
|
if (err)
|
|
|
|
goto out_err;
|
|
|
|
|
|
|
|
err = host->cqe_ops->cqe_request(host, mrq);
|
|
|
|
if (err)
|
|
|
|
goto out_err;
|
|
|
|
|
|
|
|
trace_mmc_request_start(host, mrq);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
out_err:
|
|
|
|
if (mrq->cmd) {
|
|
|
|
pr_debug("%s: failed to start CQE direct CMD%u, error %d\n",
|
|
|
|
mmc_hostname(host), mrq->cmd->opcode, err);
|
|
|
|
} else {
|
|
|
|
pr_debug("%s: failed to start CQE transfer for tag %d, error %d\n",
|
|
|
|
mmc_hostname(host), mrq->tag, err);
|
|
|
|
}
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(mmc_cqe_start_req);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* mmc_cqe_request_done - CQE has finished processing an MMC request
|
|
|
|
* @host: MMC host which completed request
|
|
|
|
* @mrq: MMC request which completed
|
|
|
|
*
|
|
|
|
* CQE drivers should call this function when they have completed
|
|
|
|
* their processing of a request.
|
|
|
|
*/
|
|
|
|
void mmc_cqe_request_done(struct mmc_host *host, struct mmc_request *mrq)
|
|
|
|
{
|
|
|
|
mmc_should_fail_request(host, mrq);
|
|
|
|
|
|
|
|
/* Flag re-tuning needed on CRC errors */
|
|
|
|
if ((mrq->cmd && mrq->cmd->error == -EILSEQ) ||
|
|
|
|
(mrq->data && mrq->data->error == -EILSEQ))
|
|
|
|
mmc_retune_needed(host);
|
|
|
|
|
|
|
|
trace_mmc_request_done(host, mrq);
|
|
|
|
|
|
|
|
if (mrq->cmd) {
|
|
|
|
pr_debug("%s: CQE req done (direct CMD%u): %d\n",
|
|
|
|
mmc_hostname(host), mrq->cmd->opcode, mrq->cmd->error);
|
|
|
|
} else {
|
|
|
|
pr_debug("%s: CQE transfer done tag %d\n",
|
|
|
|
mmc_hostname(host), mrq->tag);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (mrq->data) {
|
|
|
|
pr_debug("%s: %d bytes transferred: %d\n",
|
|
|
|
mmc_hostname(host),
|
|
|
|
mrq->data->bytes_xfered, mrq->data->error);
|
|
|
|
}
|
|
|
|
|
|
|
|
mrq->done(mrq);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(mmc_cqe_request_done);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* mmc_cqe_post_req - CQE post process of a completed MMC request
|
|
|
|
* @host: MMC host
|
|
|
|
* @mrq: MMC request to be processed
|
|
|
|
*/
|
|
|
|
void mmc_cqe_post_req(struct mmc_host *host, struct mmc_request *mrq)
|
|
|
|
{
|
|
|
|
if (host->cqe_ops->cqe_post_req)
|
|
|
|
host->cqe_ops->cqe_post_req(host, mrq);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(mmc_cqe_post_req);
|
|
|
|
|
|
|
|
/* Arbitrary 1 second timeout */
|
|
|
|
#define MMC_CQE_RECOVERY_TIMEOUT 1000
|
|
|
|
|
|
|
|
/*
|
|
|
|
* mmc_cqe_recovery - Recover from CQE errors.
|
|
|
|
* @host: MMC host to recover
|
|
|
|
*
|
|
|
|
* Recovery consists of stopping CQE, stopping eMMC, discarding the queue in
|
|
|
|
* in eMMC, and discarding the queue in CQE. CQE must call
|
|
|
|
* mmc_cqe_request_done() on all requests. An error is returned if the eMMC
|
|
|
|
* fails to discard its queue.
|
|
|
|
*/
|
|
|
|
int mmc_cqe_recovery(struct mmc_host *host)
|
|
|
|
{
|
|
|
|
struct mmc_command cmd;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
mmc_retune_hold_now(host);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Recovery is expected seldom, if at all, but it reduces performance,
|
|
|
|
* so make sure it is not completely silent.
|
|
|
|
*/
|
|
|
|
pr_warn("%s: running CQE recovery\n", mmc_hostname(host));
|
|
|
|
|
|
|
|
host->cqe_ops->cqe_recovery_start(host);
|
|
|
|
|
|
|
|
memset(&cmd, 0, sizeof(cmd));
|
|
|
|
cmd.opcode = MMC_STOP_TRANSMISSION,
|
|
|
|
cmd.flags = MMC_RSP_R1B | MMC_CMD_AC,
|
|
|
|
cmd.flags &= ~MMC_RSP_CRC; /* Ignore CRC */
|
|
|
|
cmd.busy_timeout = MMC_CQE_RECOVERY_TIMEOUT,
|
|
|
|
mmc_wait_for_cmd(host, &cmd, 0);
|
|
|
|
|
|
|
|
memset(&cmd, 0, sizeof(cmd));
|
|
|
|
cmd.opcode = MMC_CMDQ_TASK_MGMT;
|
|
|
|
cmd.arg = 1; /* Discard entire queue */
|
|
|
|
cmd.flags = MMC_RSP_R1B | MMC_CMD_AC;
|
|
|
|
cmd.flags &= ~MMC_RSP_CRC; /* Ignore CRC */
|
|
|
|
cmd.busy_timeout = MMC_CQE_RECOVERY_TIMEOUT,
|
|
|
|
err = mmc_wait_for_cmd(host, &cmd, 0);
|
|
|
|
|
|
|
|
host->cqe_ops->cqe_recovery_finish(host);
|
|
|
|
|
|
|
|
mmc_retune_release(host);
|
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(mmc_cqe_recovery);
|
|
|
|
|
mmc: core: Add support for sending commands during data transfer
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 <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-08-16 18:44:11 +08:00
|
|
|
/**
|
|
|
|
* mmc_is_req_done - Determine if a 'cap_cmd_during_tfr' request is done
|
|
|
|
* @host: MMC host
|
|
|
|
* @mrq: MMC request
|
|
|
|
*
|
|
|
|
* mmc_is_req_done() is used with requests that have
|
|
|
|
* mrq->cap_cmd_during_tfr = true. mmc_is_req_done() must be called after
|
|
|
|
* starting a request and before waiting for it to complete. That is,
|
|
|
|
* either in between calls to mmc_start_req(), or after mmc_wait_for_req()
|
|
|
|
* and before mmc_wait_for_req_done(). If it is called at other times the
|
|
|
|
* result is not meaningful.
|
|
|
|
*/
|
|
|
|
bool mmc_is_req_done(struct mmc_host *host, struct mmc_request *mrq)
|
|
|
|
{
|
2017-11-29 21:41:19 +08:00
|
|
|
return completion_done(&mrq->completion);
|
mmc: core: Add support for sending commands during data transfer
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 <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-08-16 18:44:11 +08:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(mmc_is_req_done);
|
2011-07-02 00:55:22 +08:00
|
|
|
|
2007-07-12 02:22:11 +08:00
|
|
|
/**
|
|
|
|
* mmc_wait_for_req - start a request and wait for completion
|
|
|
|
* @host: MMC host to start command
|
|
|
|
* @mrq: MMC request to start
|
|
|
|
*
|
|
|
|
* Start a new MMC custom command request for a host, and wait
|
mmc: core: Add support for sending commands during data transfer
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 <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-08-16 18:44:11 +08:00
|
|
|
* for the command to complete. In the case of 'cap_cmd_during_tfr'
|
|
|
|
* requests, the transfer is ongoing and the caller can issue further
|
|
|
|
* commands that do not use the data lines, and then wait by calling
|
|
|
|
* mmc_wait_for_req_done().
|
|
|
|
* Does not attempt to parse the response.
|
2007-07-12 02:22:11 +08:00
|
|
|
*/
|
|
|
|
void mmc_wait_for_req(struct mmc_host *host, struct mmc_request *mrq)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2011-07-02 00:55:22 +08:00
|
|
|
__mmc_start_req(host, mrq);
|
mmc: core: Add support for sending commands during data transfer
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 <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-08-16 18:44:11 +08:00
|
|
|
|
|
|
|
if (!mrq->cap_cmd_during_tfr)
|
|
|
|
mmc_wait_for_req_done(host, mrq);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(mmc_wait_for_req);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* mmc_wait_for_cmd - start a command and wait for completion
|
|
|
|
* @host: MMC host to start command
|
|
|
|
* @cmd: MMC command to start
|
|
|
|
* @retries: maximum number of retries
|
|
|
|
*
|
|
|
|
* Start a new MMC command for a host, and wait for the command
|
|
|
|
* to complete. Return any error that occurred while the command
|
|
|
|
* was executing. Do not attempt to parse the response.
|
|
|
|
*/
|
|
|
|
int mmc_wait_for_cmd(struct mmc_host *host, struct mmc_command *cmd, int retries)
|
|
|
|
{
|
2016-12-19 19:51:18 +08:00
|
|
|
struct mmc_request mrq = {};
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2007-08-09 19:23:56 +08:00
|
|
|
WARN_ON(!host->claimed);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
memset(cmd->resp, 0, sizeof(cmd->resp));
|
|
|
|
cmd->retries = retries;
|
|
|
|
|
|
|
|
mrq.cmd = cmd;
|
|
|
|
cmd->data = NULL;
|
|
|
|
|
|
|
|
mmc_wait_for_req(host, &mrq);
|
|
|
|
|
|
|
|
return cmd->error;
|
|
|
|
}
|
|
|
|
|
|
|
|
EXPORT_SYMBOL(mmc_wait_for_cmd);
|
|
|
|
|
2006-09-07 22:57:12 +08:00
|
|
|
/**
|
|
|
|
* mmc_set_data_timeout - set the timeout for a data command
|
|
|
|
* @data: data phase for command
|
|
|
|
* @card: the MMC card associated with the data transfer
|
2007-07-12 02:22:11 +08:00
|
|
|
*
|
|
|
|
* Computes the data timeout parameters according to the
|
|
|
|
* correct algorithm given the card type.
|
2006-09-07 22:57:12 +08:00
|
|
|
*/
|
2007-07-25 01:16:54 +08:00
|
|
|
void mmc_set_data_timeout(struct mmc_data *data, const struct mmc_card *card)
|
2006-09-07 22:57:12 +08:00
|
|
|
{
|
|
|
|
unsigned int mult;
|
|
|
|
|
2007-08-07 20:11:55 +08:00
|
|
|
/*
|
|
|
|
* SDIO cards only define an upper 1 s limit on access.
|
|
|
|
*/
|
|
|
|
if (mmc_card_sdio(card)) {
|
|
|
|
data->timeout_ns = 1000000000;
|
|
|
|
data->timeout_clks = 0;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2006-09-07 22:57:12 +08:00
|
|
|
/*
|
|
|
|
* SD cards use a 100 multiplier rather than 10
|
|
|
|
*/
|
|
|
|
mult = mmc_card_sd(card) ? 100 : 10;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Scale up the multiplier (and therefore the timeout) by
|
|
|
|
* the r2w factor for writes.
|
|
|
|
*/
|
2007-07-25 01:16:54 +08:00
|
|
|
if (data->flags & MMC_DATA_WRITE)
|
2006-09-07 22:57:12 +08:00
|
|
|
mult <<= card->csd.r2w_factor;
|
|
|
|
|
2017-08-02 11:12:42 +08:00
|
|
|
data->timeout_ns = card->csd.taac_ns * mult;
|
|
|
|
data->timeout_clks = card->csd.taac_clks * mult;
|
2006-09-07 22:57:12 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* SD cards also have an upper limit on the timeout.
|
|
|
|
*/
|
|
|
|
if (mmc_card_sd(card)) {
|
|
|
|
unsigned int timeout_us, limit_us;
|
|
|
|
|
|
|
|
timeout_us = data->timeout_ns / 1000;
|
2015-10-02 16:56:11 +08:00
|
|
|
if (card->host->ios.clock)
|
2011-01-05 07:44:32 +08:00
|
|
|
timeout_us += data->timeout_clks * 1000 /
|
2015-10-02 16:56:11 +08:00
|
|
|
(card->host->ios.clock / 1000);
|
2006-09-07 22:57:12 +08:00
|
|
|
|
2007-07-25 01:16:54 +08:00
|
|
|
if (data->flags & MMC_DATA_WRITE)
|
2008-10-26 19:37:25 +08:00
|
|
|
/*
|
2012-03-12 18:58:00 +08:00
|
|
|
* The MMC spec "It is strongly recommended
|
|
|
|
* for hosts to implement more than 500ms
|
|
|
|
* timeout value even if the card indicates
|
|
|
|
* the 250ms maximum busy length." Even the
|
|
|
|
* previous value of 300ms is known to be
|
|
|
|
* insufficient for some cards.
|
2008-10-26 19:37:25 +08:00
|
|
|
*/
|
2012-03-12 18:58:00 +08:00
|
|
|
limit_us = 3000000;
|
2006-09-07 22:57:12 +08:00
|
|
|
else
|
|
|
|
limit_us = 100000;
|
|
|
|
|
2007-01-04 22:57:32 +08:00
|
|
|
/*
|
|
|
|
* SDHC cards always use these fixed values.
|
|
|
|
*/
|
2017-08-07 10:07:14 +08:00
|
|
|
if (timeout_us > limit_us) {
|
2006-09-07 22:57:12 +08:00
|
|
|
data->timeout_ns = limit_us * 1000;
|
|
|
|
data->timeout_clks = 0;
|
|
|
|
}
|
2014-04-03 23:32:05 +08:00
|
|
|
|
|
|
|
/* assign limit value if invalid */
|
|
|
|
if (timeout_us == 0)
|
|
|
|
data->timeout_ns = limit_us * 1000;
|
2006-09-07 22:57:12 +08:00
|
|
|
}
|
2011-11-03 16:44:12 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Some cards require longer data read timeout than indicated in CSD.
|
|
|
|
* Address this by setting the read timeout to a "reasonably high"
|
2016-05-20 15:33:46 +08:00
|
|
|
* value. For the cards tested, 600ms has proven enough. If necessary,
|
2011-11-03 16:44:12 +08:00
|
|
|
* this value can be increased if other problematic cards require this.
|
|
|
|
*/
|
|
|
|
if (mmc_card_long_read_time(card) && data->flags & MMC_DATA_READ) {
|
2016-05-20 15:33:46 +08:00
|
|
|
data->timeout_ns = 600000000;
|
2011-11-03 16:44:12 +08:00
|
|
|
data->timeout_clks = 0;
|
|
|
|
}
|
|
|
|
|
2009-03-11 21:28:39 +08:00
|
|
|
/*
|
|
|
|
* Some cards need very high timeouts if driven in SPI mode.
|
|
|
|
* The worst observed timeout was 900ms after writing a
|
|
|
|
* continuous stream of data until the internal logic
|
|
|
|
* overflowed.
|
|
|
|
*/
|
|
|
|
if (mmc_host_is_spi(card->host)) {
|
|
|
|
if (data->flags & MMC_DATA_WRITE) {
|
|
|
|
if (data->timeout_ns < 1000000000)
|
|
|
|
data->timeout_ns = 1000000000; /* 1s */
|
|
|
|
} else {
|
|
|
|
if (data->timeout_ns < 100000000)
|
|
|
|
data->timeout_ns = 100000000; /* 100ms */
|
|
|
|
}
|
|
|
|
}
|
2006-09-07 22:57:12 +08:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(mmc_set_data_timeout);
|
|
|
|
|
2017-09-22 20:36:51 +08:00
|
|
|
/*
|
|
|
|
* Allow claiming an already claimed host if the context is the same or there is
|
|
|
|
* no context but the task is the same.
|
|
|
|
*/
|
|
|
|
static inline bool mmc_ctx_matches(struct mmc_host *host, struct mmc_ctx *ctx,
|
|
|
|
struct task_struct *task)
|
|
|
|
{
|
|
|
|
return host->claimer == ctx ||
|
|
|
|
(!ctx && task && host->claimer->task == task);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void mmc_ctx_set_claimer(struct mmc_host *host,
|
|
|
|
struct mmc_ctx *ctx,
|
|
|
|
struct task_struct *task)
|
|
|
|
{
|
|
|
|
if (!host->claimer) {
|
|
|
|
if (ctx)
|
|
|
|
host->claimer = ctx;
|
|
|
|
else
|
|
|
|
host->claimer = &host->default_ctx;
|
|
|
|
}
|
|
|
|
if (task)
|
|
|
|
host->claimer->task = task;
|
|
|
|
}
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/**
|
2007-06-30 22:21:52 +08:00
|
|
|
* __mmc_claim_host - exclusively claim a host
|
2005-04-17 06:20:36 +08:00
|
|
|
* @host: mmc host to claim
|
2017-09-22 20:36:51 +08:00
|
|
|
* @ctx: context that claims the host or NULL in which case the default
|
|
|
|
* context will be used
|
2007-06-30 22:21:52 +08:00
|
|
|
* @abort: whether or not the operation should be aborted
|
2005-04-17 06:20:36 +08:00
|
|
|
*
|
2007-06-30 22:21:52 +08:00
|
|
|
* Claim a host for a set of operations. If @abort is non null and
|
|
|
|
* dereference a non-zero value then this will return prematurely with
|
|
|
|
* that non-zero value without acquiring the lock. Returns zero
|
|
|
|
* with the lock held otherwise.
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
2017-09-22 20:36:51 +08:00
|
|
|
int __mmc_claim_host(struct mmc_host *host, struct mmc_ctx *ctx,
|
|
|
|
atomic_t *abort)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2017-09-22 20:36:51 +08:00
|
|
|
struct task_struct *task = ctx ? NULL : current;
|
2005-04-17 06:20:36 +08:00
|
|
|
DECLARE_WAITQUEUE(wait, current);
|
|
|
|
unsigned long flags;
|
2007-06-30 22:21:52 +08:00
|
|
|
int stop;
|
2015-03-27 19:15:15 +08:00
|
|
|
bool pm = false;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2007-07-12 02:28:02 +08:00
|
|
|
might_sleep();
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
add_wait_queue(&host->wq, &wait);
|
|
|
|
spin_lock_irqsave(&host->lock, flags);
|
|
|
|
while (1) {
|
|
|
|
set_current_state(TASK_UNINTERRUPTIBLE);
|
2007-06-30 22:21:52 +08:00
|
|
|
stop = abort ? atomic_read(abort) : 0;
|
2017-09-22 20:36:51 +08:00
|
|
|
if (stop || !host->claimed || mmc_ctx_matches(host, ctx, task))
|
2005-04-17 06:20:36 +08:00
|
|
|
break;
|
|
|
|
spin_unlock_irqrestore(&host->lock, flags);
|
|
|
|
schedule();
|
|
|
|
spin_lock_irqsave(&host->lock, flags);
|
|
|
|
}
|
|
|
|
set_current_state(TASK_RUNNING);
|
2009-09-23 07:44:30 +08:00
|
|
|
if (!stop) {
|
2007-06-30 22:21:52 +08:00
|
|
|
host->claimed = 1;
|
2017-09-22 20:36:51 +08:00
|
|
|
mmc_ctx_set_claimer(host, ctx, task);
|
2009-09-23 07:44:30 +08:00
|
|
|
host->claim_cnt += 1;
|
2015-03-27 19:15:15 +08:00
|
|
|
if (host->claim_cnt == 1)
|
|
|
|
pm = true;
|
2009-09-23 07:44:30 +08:00
|
|
|
} else
|
2007-06-30 22:21:52 +08:00
|
|
|
wake_up(&host->wq);
|
2005-04-17 06:20:36 +08:00
|
|
|
spin_unlock_irqrestore(&host->lock, flags);
|
|
|
|
remove_wait_queue(&host->wq, &wait);
|
2015-03-27 19:15:15 +08:00
|
|
|
|
|
|
|
if (pm)
|
|
|
|
pm_runtime_get_sync(mmc_dev(host));
|
|
|
|
|
2007-06-30 22:21:52 +08:00
|
|
|
return stop;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
2007-06-30 22:21:52 +08:00
|
|
|
EXPORT_SYMBOL(__mmc_claim_host);
|
2009-09-23 07:44:29 +08:00
|
|
|
|
2011-03-09 16:11:02 +08:00
|
|
|
/**
|
2012-02-29 15:17:21 +08:00
|
|
|
* mmc_release_host - release a host
|
2011-03-09 16:11:02 +08:00
|
|
|
* @host: mmc host to release
|
|
|
|
*
|
2012-02-29 15:17:21 +08:00
|
|
|
* Release a MMC host, allowing others to claim the host
|
|
|
|
* for their operations.
|
2011-03-09 16:11:02 +08:00
|
|
|
*/
|
2012-02-29 15:17:21 +08:00
|
|
|
void mmc_release_host(struct mmc_host *host)
|
2009-09-23 07:44:29 +08:00
|
|
|
{
|
|
|
|
unsigned long flags;
|
|
|
|
|
2012-02-29 15:17:21 +08:00
|
|
|
WARN_ON(!host->claimed);
|
|
|
|
|
2009-09-23 07:44:29 +08:00
|
|
|
spin_lock_irqsave(&host->lock, flags);
|
2009-09-23 07:44:30 +08:00
|
|
|
if (--host->claim_cnt) {
|
|
|
|
/* Release for nested claim */
|
|
|
|
spin_unlock_irqrestore(&host->lock, flags);
|
|
|
|
} else {
|
|
|
|
host->claimed = 0;
|
2017-09-22 20:36:51 +08:00
|
|
|
host->claimer->task = NULL;
|
2009-09-23 07:44:30 +08:00
|
|
|
host->claimer = NULL;
|
|
|
|
spin_unlock_irqrestore(&host->lock, flags);
|
|
|
|
wake_up(&host->wq);
|
2015-03-27 19:15:15 +08:00
|
|
|
pm_runtime_mark_last_busy(mmc_dev(host));
|
2018-05-31 17:40:38 +08:00
|
|
|
if (host->caps & MMC_CAP_SYNC_RUNTIME_PM)
|
|
|
|
pm_runtime_put_sync_suspend(mmc_dev(host));
|
|
|
|
else
|
|
|
|
pm_runtime_put_autosuspend(mmc_dev(host));
|
2009-09-23 07:44:30 +08:00
|
|
|
}
|
2009-09-23 07:44:29 +08:00
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
EXPORT_SYMBOL(mmc_release_host);
|
|
|
|
|
2013-05-02 20:02:38 +08:00
|
|
|
/*
|
|
|
|
* This is a helper function, which fetches a runtime pm reference for the
|
|
|
|
* card device and also claims the host.
|
|
|
|
*/
|
2017-09-22 20:36:51 +08:00
|
|
|
void mmc_get_card(struct mmc_card *card, struct mmc_ctx *ctx)
|
2013-05-02 20:02:38 +08:00
|
|
|
{
|
|
|
|
pm_runtime_get_sync(&card->dev);
|
2017-09-22 20:36:51 +08:00
|
|
|
__mmc_claim_host(card->host, ctx, NULL);
|
2013-05-02 20:02:38 +08:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(mmc_get_card);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This is a helper function, which releases the host and drops the runtime
|
|
|
|
* pm reference for the card device.
|
|
|
|
*/
|
2017-09-22 20:36:51 +08:00
|
|
|
void mmc_put_card(struct mmc_card *card, struct mmc_ctx *ctx)
|
2013-05-02 20:02:38 +08:00
|
|
|
{
|
2017-09-22 20:36:51 +08:00
|
|
|
struct mmc_host *host = card->host;
|
|
|
|
|
|
|
|
WARN_ON(ctx && host->claimer != ctx);
|
|
|
|
|
|
|
|
mmc_release_host(host);
|
2013-05-02 20:02:38 +08:00
|
|
|
pm_runtime_mark_last_busy(&card->dev);
|
|
|
|
pm_runtime_put_autosuspend(&card->dev);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(mmc_put_card);
|
|
|
|
|
2006-12-31 07:11:32 +08:00
|
|
|
/*
|
|
|
|
* Internal function that does the actual ios call to the host driver,
|
|
|
|
* optionally printing some debug output.
|
|
|
|
*/
|
2006-05-05 01:22:51 +08:00
|
|
|
static inline void mmc_set_ios(struct mmc_host *host)
|
|
|
|
{
|
|
|
|
struct mmc_ios *ios = &host->ios;
|
|
|
|
|
2007-02-18 19:07:47 +08:00
|
|
|
pr_debug("%s: clock %uHz busmode %u powermode %u cs %u Vdd %u "
|
|
|
|
"width %u timing %u\n",
|
2006-05-05 01:22:51 +08:00
|
|
|
mmc_hostname(host), ios->clock, ios->bus_mode,
|
|
|
|
ios->power_mode, ios->chip_select, ios->vdd,
|
2016-01-29 16:27:50 +08:00
|
|
|
1 << ios->bus_width, ios->timing);
|
2007-01-04 22:57:32 +08:00
|
|
|
|
2006-05-05 01:22:51 +08:00
|
|
|
host->ops->set_ios(host, ios);
|
|
|
|
}
|
|
|
|
|
2006-12-31 07:11:32 +08:00
|
|
|
/*
|
|
|
|
* Control chip select pin on a host.
|
|
|
|
*/
|
2006-12-25 05:46:55 +08:00
|
|
|
void mmc_set_chip_select(struct mmc_host *host, int mode)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2006-12-25 05:46:55 +08:00
|
|
|
host->ios.chip_select = mode;
|
|
|
|
mmc_set_ios(host);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2006-12-31 07:11:32 +08:00
|
|
|
/*
|
|
|
|
* Sets the host clock to the highest possible frequency that
|
|
|
|
* is below "hz".
|
|
|
|
*/
|
2015-10-02 16:56:11 +08:00
|
|
|
void mmc_set_clock(struct mmc_host *host, unsigned int hz)
|
2006-12-31 07:11:32 +08:00
|
|
|
{
|
2014-09-24 04:00:26 +08:00
|
|
|
WARN_ON(hz && hz < host->f_min);
|
2006-12-31 07:11:32 +08:00
|
|
|
|
|
|
|
if (hz > host->f_max)
|
|
|
|
hz = host->f_max;
|
|
|
|
|
|
|
|
host->ios.clock = hz;
|
|
|
|
mmc_set_ios(host);
|
|
|
|
}
|
|
|
|
|
2014-12-06 01:40:59 +08:00
|
|
|
int mmc_execute_tuning(struct mmc_card *card)
|
|
|
|
{
|
|
|
|
struct mmc_host *host = card->host;
|
|
|
|
u32 opcode;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
if (!host->ops->execute_tuning)
|
|
|
|
return 0;
|
|
|
|
|
2017-08-10 20:08:09 +08:00
|
|
|
if (host->cqe_on)
|
|
|
|
host->cqe_ops->cqe_off(host);
|
|
|
|
|
2014-12-06 01:40:59 +08:00
|
|
|
if (mmc_card_mmc(card))
|
|
|
|
opcode = MMC_SEND_TUNING_BLOCK_HS200;
|
|
|
|
else
|
|
|
|
opcode = MMC_SEND_TUNING_BLOCK;
|
|
|
|
|
|
|
|
err = host->ops->execute_tuning(host, opcode);
|
|
|
|
|
|
|
|
if (err)
|
2016-01-29 17:44:05 +08:00
|
|
|
pr_err("%s: tuning execution failed: %d\n",
|
|
|
|
mmc_hostname(host), err);
|
2015-05-07 18:10:13 +08:00
|
|
|
else
|
|
|
|
mmc_retune_enable(host);
|
2014-12-06 01:40:59 +08:00
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2006-12-31 07:11:32 +08:00
|
|
|
/*
|
|
|
|
* Change the bus mode (open drain/push-pull) of a host.
|
|
|
|
*/
|
|
|
|
void mmc_set_bus_mode(struct mmc_host *host, unsigned int mode)
|
|
|
|
{
|
|
|
|
host->ios.bus_mode = mode;
|
|
|
|
mmc_set_ios(host);
|
|
|
|
}
|
|
|
|
|
2010-08-24 18:20:26 +08:00
|
|
|
/*
|
|
|
|
* Change data bus width of a host.
|
|
|
|
*/
|
|
|
|
void mmc_set_bus_width(struct mmc_host *host, unsigned int width)
|
|
|
|
{
|
2011-05-13 13:47:18 +08:00
|
|
|
host->ios.bus_width = width;
|
|
|
|
mmc_set_ios(host);
|
2010-08-24 18:20:26 +08:00
|
|
|
}
|
|
|
|
|
2014-11-06 21:46:54 +08:00
|
|
|
/*
|
|
|
|
* Set initial state after a power cycle or a hw_reset.
|
|
|
|
*/
|
|
|
|
void mmc_set_initial_state(struct mmc_host *host)
|
|
|
|
{
|
2017-08-10 20:08:09 +08:00
|
|
|
if (host->cqe_on)
|
|
|
|
host->cqe_ops->cqe_off(host);
|
|
|
|
|
2015-05-07 18:10:13 +08:00
|
|
|
mmc_retune_disable(host);
|
|
|
|
|
2014-11-06 21:46:54 +08:00
|
|
|
if (mmc_host_is_spi(host))
|
|
|
|
host->ios.chip_select = MMC_CS_HIGH;
|
|
|
|
else
|
|
|
|
host->ios.chip_select = MMC_CS_DONTCARE;
|
|
|
|
host->ios.bus_mode = MMC_BUSMODE_PUSHPULL;
|
|
|
|
host->ios.bus_width = MMC_BUS_WIDTH_1;
|
|
|
|
host->ios.timing = MMC_TIMING_LEGACY;
|
2015-02-06 20:12:51 +08:00
|
|
|
host->ios.drv_type = 0;
|
2016-05-26 09:56:22 +08:00
|
|
|
host->ios.enhanced_strobe = false;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Make sure we are in non-enhanced strobe mode before we
|
|
|
|
* actually enable it in ext_csd.
|
|
|
|
*/
|
|
|
|
if ((host->caps2 & MMC_CAP2_HS400_ES) &&
|
|
|
|
host->ops->hs400_enhanced_strobe)
|
|
|
|
host->ops->hs400_enhanced_strobe(host, &host->ios);
|
2014-11-06 21:46:54 +08:00
|
|
|
|
|
|
|
mmc_set_ios(host);
|
|
|
|
}
|
|
|
|
|
2008-11-27 03:54:17 +08:00
|
|
|
/**
|
|
|
|
* mmc_vdd_to_ocrbitnum - Convert a voltage to the OCR bit number
|
|
|
|
* @vdd: voltage (mV)
|
|
|
|
* @low_bits: prefer low bits in boundary cases
|
|
|
|
*
|
|
|
|
* This function returns the OCR bit number according to the provided @vdd
|
|
|
|
* value. If conversion is not possible a negative errno value returned.
|
|
|
|
*
|
|
|
|
* Depending on the @low_bits flag the function prefers low or high OCR bits
|
|
|
|
* on boundary voltages. For example,
|
|
|
|
* with @low_bits = true, 3300 mV translates to ilog2(MMC_VDD_32_33);
|
|
|
|
* with @low_bits = false, 3300 mV translates to ilog2(MMC_VDD_33_34);
|
|
|
|
*
|
|
|
|
* Any value in the [1951:1999] range translates to the ilog2(MMC_VDD_20_21).
|
|
|
|
*/
|
|
|
|
static int mmc_vdd_to_ocrbitnum(int vdd, bool low_bits)
|
|
|
|
{
|
|
|
|
const int max_bit = ilog2(MMC_VDD_35_36);
|
|
|
|
int bit;
|
|
|
|
|
|
|
|
if (vdd < 1650 || vdd > 3600)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (vdd >= 1650 && vdd <= 1950)
|
|
|
|
return ilog2(MMC_VDD_165_195);
|
|
|
|
|
|
|
|
if (low_bits)
|
|
|
|
vdd -= 1;
|
|
|
|
|
|
|
|
/* Base 2000 mV, step 100 mV, bit's base 8. */
|
|
|
|
bit = (vdd - 2000) / 100 + 8;
|
|
|
|
if (bit > max_bit)
|
|
|
|
return max_bit;
|
|
|
|
return bit;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* mmc_vddrange_to_ocrmask - Convert a voltage range to the OCR mask
|
|
|
|
* @vdd_min: minimum voltage value (mV)
|
|
|
|
* @vdd_max: maximum voltage value (mV)
|
|
|
|
*
|
|
|
|
* This function returns the OCR mask bits according to the provided @vdd_min
|
|
|
|
* and @vdd_max values. If conversion is not possible the function returns 0.
|
|
|
|
*
|
|
|
|
* Notes wrt boundary cases:
|
|
|
|
* This function sets the OCR bits for all boundary voltages, for example
|
|
|
|
* [3300:3400] range is translated to MMC_VDD_32_33 | MMC_VDD_33_34 |
|
|
|
|
* MMC_VDD_34_35 mask.
|
|
|
|
*/
|
|
|
|
u32 mmc_vddrange_to_ocrmask(int vdd_min, int vdd_max)
|
|
|
|
{
|
|
|
|
u32 mask = 0;
|
|
|
|
|
|
|
|
if (vdd_max < vdd_min)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/* Prefer high bits for the boundary vdd_max values. */
|
|
|
|
vdd_max = mmc_vdd_to_ocrbitnum(vdd_max, false);
|
|
|
|
if (vdd_max < 0)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/* Prefer low bits for the boundary vdd_min values. */
|
|
|
|
vdd_min = mmc_vdd_to_ocrbitnum(vdd_min, true);
|
|
|
|
if (vdd_min < 0)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/* Fill the mask, from max bit to min bit. */
|
|
|
|
while (vdd_max >= vdd_min)
|
|
|
|
mask |= 1 << vdd_max--;
|
|
|
|
|
|
|
|
return mask;
|
|
|
|
}
|
|
|
|
|
2014-06-30 17:07:25 +08:00
|
|
|
static int mmc_of_get_func_num(struct device_node *node)
|
|
|
|
{
|
|
|
|
u32 reg;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
ret = of_property_read_u32(node, "reg", ®);
|
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
return reg;
|
|
|
|
}
|
|
|
|
|
|
|
|
struct device_node *mmc_of_find_child_device(struct mmc_host *host,
|
|
|
|
unsigned func_num)
|
|
|
|
{
|
|
|
|
struct device_node *node;
|
|
|
|
|
|
|
|
if (!host->parent || !host->parent->of_node)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
for_each_child_of_node(host->parent->of_node, node) {
|
|
|
|
if (mmc_of_get_func_num(node) == func_num)
|
|
|
|
return node;
|
|
|
|
}
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/*
|
|
|
|
* Mask off any voltages we don't support and select
|
|
|
|
* the lowest voltage
|
|
|
|
*/
|
2006-12-31 07:11:32 +08:00
|
|
|
u32 mmc_select_voltage(struct mmc_host *host, u32 ocr)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
|
|
|
int bit;
|
|
|
|
|
2013-09-16 18:06:15 +08:00
|
|
|
/*
|
|
|
|
* Sanity check the voltages that the card claims to
|
|
|
|
* support.
|
|
|
|
*/
|
|
|
|
if (ocr & 0x7F) {
|
|
|
|
dev_warn(mmc_dev(host),
|
|
|
|
"card claims to support voltages below defined range\n");
|
|
|
|
ocr &= ~0x7F;
|
|
|
|
}
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
ocr &= host->ocr_avail;
|
2013-09-16 17:28:42 +08:00
|
|
|
if (!ocr) {
|
|
|
|
dev_warn(mmc_dev(host), "no support for card's volts\n");
|
|
|
|
return 0;
|
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2013-09-16 17:28:42 +08:00
|
|
|
if (host->caps2 & MMC_CAP2_FULL_PWR_CYCLE) {
|
|
|
|
bit = ffs(ocr) - 1;
|
2006-11-03 02:43:27 +08:00
|
|
|
ocr &= 3 << bit;
|
2013-09-16 17:28:42 +08:00
|
|
|
mmc_power_cycle(host, ocr);
|
2005-04-17 06:20:36 +08:00
|
|
|
} else {
|
2013-09-16 17:28:42 +08:00
|
|
|
bit = fls(ocr) - 1;
|
|
|
|
ocr &= 3 << bit;
|
|
|
|
if (bit != host->ios.vdd)
|
|
|
|
dev_warn(mmc_dev(host), "exceeding card's volts\n");
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
return ocr;
|
|
|
|
}
|
|
|
|
|
2017-01-25 18:12:34 +08:00
|
|
|
int mmc_set_signal_voltage(struct mmc_host *host, int signal_voltage)
|
2013-01-28 22:08:27 +08:00
|
|
|
{
|
|
|
|
int err = 0;
|
|
|
|
int old_signal_voltage = host->ios.signal_voltage;
|
|
|
|
|
|
|
|
host->ios.signal_voltage = signal_voltage;
|
2015-10-02 16:56:11 +08:00
|
|
|
if (host->ops->start_signal_voltage_switch)
|
2013-01-28 22:08:27 +08:00
|
|
|
err = host->ops->start_signal_voltage_switch(host, &host->ios);
|
|
|
|
|
|
|
|
if (err)
|
|
|
|
host->ios.signal_voltage = old_signal_voltage;
|
|
|
|
|
|
|
|
return err;
|
|
|
|
|
|
|
|
}
|
|
|
|
|
2018-04-06 03:24:15 +08:00
|
|
|
void mmc_set_initial_signal_voltage(struct mmc_host *host)
|
|
|
|
{
|
|
|
|
/* Try to set signal voltage to 3.3V but fall back to 1.8v or 1.2v */
|
|
|
|
if (!mmc_set_signal_voltage(host, MMC_SIGNAL_VOLTAGE_330))
|
|
|
|
dev_dbg(mmc_dev(host), "Initial signal voltage of 3.3v\n");
|
|
|
|
else if (!mmc_set_signal_voltage(host, MMC_SIGNAL_VOLTAGE_180))
|
|
|
|
dev_dbg(mmc_dev(host), "Initial signal voltage of 1.8v\n");
|
|
|
|
else if (!mmc_set_signal_voltage(host, MMC_SIGNAL_VOLTAGE_120))
|
|
|
|
dev_dbg(mmc_dev(host), "Initial signal voltage of 1.2v\n");
|
|
|
|
}
|
|
|
|
|
2017-09-25 16:29:03 +08:00
|
|
|
int mmc_host_set_uhs_voltage(struct mmc_host *host)
|
|
|
|
{
|
|
|
|
u32 clock;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* During a signal voltage level switch, the clock must be gated
|
|
|
|
* for 5 ms according to the SD spec
|
|
|
|
*/
|
|
|
|
clock = host->ios.clock;
|
|
|
|
host->ios.clock = 0;
|
|
|
|
mmc_set_ios(host);
|
|
|
|
|
|
|
|
if (mmc_set_signal_voltage(host, MMC_SIGNAL_VOLTAGE_180))
|
|
|
|
return -EAGAIN;
|
|
|
|
|
|
|
|
/* Keep clock gated for at least 10 ms, though spec only says 5 ms */
|
|
|
|
mmc_delay(10);
|
|
|
|
host->ios.clock = clock;
|
|
|
|
mmc_set_ios(host);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2017-01-25 17:25:01 +08:00
|
|
|
int mmc_set_uhs_voltage(struct mmc_host *host, u32 ocr)
|
mmc: sd: add support for signal voltage switch procedure
Host Controller v3.00 adds another Capabilities register. Apart
from other things, this new register indicates whether the Host
Controller supports SDR50, SDR104, and DDR50 UHS-I modes. The spec
doesn't mention about explicit support for SDR12 and SDR25 UHS-I
modes, so the Host Controller v3.00 should support them by default.
Also if the controller supports SDR104 mode, it will also support
SDR50 mode as well. So depending on the host support, we set the
corresponding MMC_CAP_* flags. One more new register. Host Control2
is added in v3.00, which is used during Signal Voltage Switch
procedure described below.
Since as per v3.00 spec, UHS-I supported hosts should set S18R
to 1, we set S18R (bit 24) of OCR before sending ACMD41. We also
need to set XPC (bit 28) of OCR in case the host can supply >150mA.
This support is indicated by the Maximum Current Capabilities
register of the Host Controller.
If the response of ACMD41 has both CCS and S18A set, we start the
signal voltage switch procedure, which if successfull, will switch
the card from 3.3V signalling to 1.8V signalling. Signal voltage
switch procedure adds support for a new command CMD11 in the
Physical Layer Spec v3.01. As part of this procedure, we need to
set 1.8V Signalling Enable (bit 3) of Host Control2 register, which
if remains set after 5ms, means the switch to 1.8V signalling is
successfull. Otherwise, we clear bit 24 of OCR and retry the
initialization sequence. When we remove the card, and insert the
same or another card, we need to make sure that we start with 3.3V
signalling voltage. So we call mmc_set_signal_voltage() with
MMC_SIGNAL_VOLTAGE_330 set so that we are back to 3.3V signalling
voltage before we actually start initializing the card.
Tested by Zhangfei Gao with a Toshiba uhs card and general hs card,
on mmp2 in SDMA mode.
Signed-off-by: Arindam Nath <arindam.nath@amd.com>
Reviewed-by: Philip Rakity <prakity@marvell.com>
Tested-by: Philip Rakity <prakity@marvell.com>
Acked-by: Zhangfei Gao <zhangfei.gao@marvell.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
2011-05-05 14:48:57 +08:00
|
|
|
{
|
2016-12-19 19:51:18 +08:00
|
|
|
struct mmc_command cmd = {};
|
mmc: sd: add support for signal voltage switch procedure
Host Controller v3.00 adds another Capabilities register. Apart
from other things, this new register indicates whether the Host
Controller supports SDR50, SDR104, and DDR50 UHS-I modes. The spec
doesn't mention about explicit support for SDR12 and SDR25 UHS-I
modes, so the Host Controller v3.00 should support them by default.
Also if the controller supports SDR104 mode, it will also support
SDR50 mode as well. So depending on the host support, we set the
corresponding MMC_CAP_* flags. One more new register. Host Control2
is added in v3.00, which is used during Signal Voltage Switch
procedure described below.
Since as per v3.00 spec, UHS-I supported hosts should set S18R
to 1, we set S18R (bit 24) of OCR before sending ACMD41. We also
need to set XPC (bit 28) of OCR in case the host can supply >150mA.
This support is indicated by the Maximum Current Capabilities
register of the Host Controller.
If the response of ACMD41 has both CCS and S18A set, we start the
signal voltage switch procedure, which if successfull, will switch
the card from 3.3V signalling to 1.8V signalling. Signal voltage
switch procedure adds support for a new command CMD11 in the
Physical Layer Spec v3.01. As part of this procedure, we need to
set 1.8V Signalling Enable (bit 3) of Host Control2 register, which
if remains set after 5ms, means the switch to 1.8V signalling is
successfull. Otherwise, we clear bit 24 of OCR and retry the
initialization sequence. When we remove the card, and insert the
same or another card, we need to make sure that we start with 3.3V
signalling voltage. So we call mmc_set_signal_voltage() with
MMC_SIGNAL_VOLTAGE_330 set so that we are back to 3.3V signalling
voltage before we actually start initializing the card.
Tested by Zhangfei Gao with a Toshiba uhs card and general hs card,
on mmp2 in SDMA mode.
Signed-off-by: Arindam Nath <arindam.nath@amd.com>
Reviewed-by: Philip Rakity <prakity@marvell.com>
Tested-by: Philip Rakity <prakity@marvell.com>
Acked-by: Zhangfei Gao <zhangfei.gao@marvell.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
2011-05-05 14:48:57 +08:00
|
|
|
int err = 0;
|
|
|
|
|
2013-01-28 22:08:28 +08:00
|
|
|
/*
|
|
|
|
* If we cannot switch voltages, return failure so the caller
|
|
|
|
* can continue without UHS mode
|
|
|
|
*/
|
|
|
|
if (!host->ops->start_signal_voltage_switch)
|
|
|
|
return -EPERM;
|
|
|
|
if (!host->ops->card_busy)
|
2014-09-13 05:56:56 +08:00
|
|
|
pr_warn("%s: cannot verify signal voltage switch\n",
|
|
|
|
mmc_hostname(host));
|
2013-01-28 22:08:28 +08:00
|
|
|
|
|
|
|
cmd.opcode = SD_SWITCH_VOLTAGE;
|
|
|
|
cmd.arg = 0;
|
|
|
|
cmd.flags = MMC_RSP_R1 | MMC_CMD_AC;
|
|
|
|
|
|
|
|
err = mmc_wait_for_cmd(host, &cmd, 0);
|
|
|
|
if (err)
|
2015-10-02 16:56:11 +08:00
|
|
|
return err;
|
|
|
|
|
|
|
|
if (!mmc_host_is_spi(host) && (cmd.resp[0] & R1_ERROR))
|
|
|
|
return -EIO;
|
2013-01-28 22:08:28 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* The card should drive cmd and dat[0:3] low immediately
|
|
|
|
* after the response of cmd11, but wait 1 ms to be sure
|
|
|
|
*/
|
|
|
|
mmc_delay(1);
|
|
|
|
if (host->ops->card_busy && !host->ops->card_busy(host)) {
|
|
|
|
err = -EAGAIN;
|
|
|
|
goto power_cycle;
|
|
|
|
}
|
mmc: sd: add support for signal voltage switch procedure
Host Controller v3.00 adds another Capabilities register. Apart
from other things, this new register indicates whether the Host
Controller supports SDR50, SDR104, and DDR50 UHS-I modes. The spec
doesn't mention about explicit support for SDR12 and SDR25 UHS-I
modes, so the Host Controller v3.00 should support them by default.
Also if the controller supports SDR104 mode, it will also support
SDR50 mode as well. So depending on the host support, we set the
corresponding MMC_CAP_* flags. One more new register. Host Control2
is added in v3.00, which is used during Signal Voltage Switch
procedure described below.
Since as per v3.00 spec, UHS-I supported hosts should set S18R
to 1, we set S18R (bit 24) of OCR before sending ACMD41. We also
need to set XPC (bit 28) of OCR in case the host can supply >150mA.
This support is indicated by the Maximum Current Capabilities
register of the Host Controller.
If the response of ACMD41 has both CCS and S18A set, we start the
signal voltage switch procedure, which if successfull, will switch
the card from 3.3V signalling to 1.8V signalling. Signal voltage
switch procedure adds support for a new command CMD11 in the
Physical Layer Spec v3.01. As part of this procedure, we need to
set 1.8V Signalling Enable (bit 3) of Host Control2 register, which
if remains set after 5ms, means the switch to 1.8V signalling is
successfull. Otherwise, we clear bit 24 of OCR and retry the
initialization sequence. When we remove the card, and insert the
same or another card, we need to make sure that we start with 3.3V
signalling voltage. So we call mmc_set_signal_voltage() with
MMC_SIGNAL_VOLTAGE_330 set so that we are back to 3.3V signalling
voltage before we actually start initializing the card.
Tested by Zhangfei Gao with a Toshiba uhs card and general hs card,
on mmp2 in SDMA mode.
Signed-off-by: Arindam Nath <arindam.nath@amd.com>
Reviewed-by: Philip Rakity <prakity@marvell.com>
Tested-by: Philip Rakity <prakity@marvell.com>
Acked-by: Zhangfei Gao <zhangfei.gao@marvell.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
2011-05-05 14:48:57 +08:00
|
|
|
|
2017-09-25 16:29:03 +08:00
|
|
|
if (mmc_host_set_uhs_voltage(host)) {
|
2013-01-28 22:08:28 +08:00
|
|
|
/*
|
|
|
|
* Voltages may not have been switched, but we've already
|
|
|
|
* sent CMD11, so a power cycle is required anyway
|
|
|
|
*/
|
|
|
|
err = -EAGAIN;
|
|
|
|
goto power_cycle;
|
mmc: sd: add support for signal voltage switch procedure
Host Controller v3.00 adds another Capabilities register. Apart
from other things, this new register indicates whether the Host
Controller supports SDR50, SDR104, and DDR50 UHS-I modes. The spec
doesn't mention about explicit support for SDR12 and SDR25 UHS-I
modes, so the Host Controller v3.00 should support them by default.
Also if the controller supports SDR104 mode, it will also support
SDR50 mode as well. So depending on the host support, we set the
corresponding MMC_CAP_* flags. One more new register. Host Control2
is added in v3.00, which is used during Signal Voltage Switch
procedure described below.
Since as per v3.00 spec, UHS-I supported hosts should set S18R
to 1, we set S18R (bit 24) of OCR before sending ACMD41. We also
need to set XPC (bit 28) of OCR in case the host can supply >150mA.
This support is indicated by the Maximum Current Capabilities
register of the Host Controller.
If the response of ACMD41 has both CCS and S18A set, we start the
signal voltage switch procedure, which if successfull, will switch
the card from 3.3V signalling to 1.8V signalling. Signal voltage
switch procedure adds support for a new command CMD11 in the
Physical Layer Spec v3.01. As part of this procedure, we need to
set 1.8V Signalling Enable (bit 3) of Host Control2 register, which
if remains set after 5ms, means the switch to 1.8V signalling is
successfull. Otherwise, we clear bit 24 of OCR and retry the
initialization sequence. When we remove the card, and insert the
same or another card, we need to make sure that we start with 3.3V
signalling voltage. So we call mmc_set_signal_voltage() with
MMC_SIGNAL_VOLTAGE_330 set so that we are back to 3.3V signalling
voltage before we actually start initializing the card.
Tested by Zhangfei Gao with a Toshiba uhs card and general hs card,
on mmp2 in SDMA mode.
Signed-off-by: Arindam Nath <arindam.nath@amd.com>
Reviewed-by: Philip Rakity <prakity@marvell.com>
Tested-by: Philip Rakity <prakity@marvell.com>
Acked-by: Zhangfei Gao <zhangfei.gao@marvell.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
2011-05-05 14:48:57 +08:00
|
|
|
}
|
|
|
|
|
2013-01-28 22:08:28 +08:00
|
|
|
/* Wait for at least 1 ms according to spec */
|
|
|
|
mmc_delay(1);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Failure to switch is indicated by the card holding
|
|
|
|
* dat[0:3] low
|
|
|
|
*/
|
|
|
|
if (host->ops->card_busy && host->ops->card_busy(host))
|
|
|
|
err = -EAGAIN;
|
|
|
|
|
|
|
|
power_cycle:
|
|
|
|
if (err) {
|
|
|
|
pr_debug("%s: Signal voltage switch failed, "
|
|
|
|
"power cycling card\n", mmc_hostname(host));
|
2013-09-12 21:36:34 +08:00
|
|
|
mmc_power_cycle(host, ocr);
|
2013-01-28 22:08:28 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
return err;
|
mmc: sd: add support for signal voltage switch procedure
Host Controller v3.00 adds another Capabilities register. Apart
from other things, this new register indicates whether the Host
Controller supports SDR50, SDR104, and DDR50 UHS-I modes. The spec
doesn't mention about explicit support for SDR12 and SDR25 UHS-I
modes, so the Host Controller v3.00 should support them by default.
Also if the controller supports SDR104 mode, it will also support
SDR50 mode as well. So depending on the host support, we set the
corresponding MMC_CAP_* flags. One more new register. Host Control2
is added in v3.00, which is used during Signal Voltage Switch
procedure described below.
Since as per v3.00 spec, UHS-I supported hosts should set S18R
to 1, we set S18R (bit 24) of OCR before sending ACMD41. We also
need to set XPC (bit 28) of OCR in case the host can supply >150mA.
This support is indicated by the Maximum Current Capabilities
register of the Host Controller.
If the response of ACMD41 has both CCS and S18A set, we start the
signal voltage switch procedure, which if successfull, will switch
the card from 3.3V signalling to 1.8V signalling. Signal voltage
switch procedure adds support for a new command CMD11 in the
Physical Layer Spec v3.01. As part of this procedure, we need to
set 1.8V Signalling Enable (bit 3) of Host Control2 register, which
if remains set after 5ms, means the switch to 1.8V signalling is
successfull. Otherwise, we clear bit 24 of OCR and retry the
initialization sequence. When we remove the card, and insert the
same or another card, we need to make sure that we start with 3.3V
signalling voltage. So we call mmc_set_signal_voltage() with
MMC_SIGNAL_VOLTAGE_330 set so that we are back to 3.3V signalling
voltage before we actually start initializing the card.
Tested by Zhangfei Gao with a Toshiba uhs card and general hs card,
on mmp2 in SDMA mode.
Signed-off-by: Arindam Nath <arindam.nath@amd.com>
Reviewed-by: Philip Rakity <prakity@marvell.com>
Tested-by: Philip Rakity <prakity@marvell.com>
Acked-by: Zhangfei Gao <zhangfei.gao@marvell.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
2011-05-05 14:48:57 +08:00
|
|
|
}
|
|
|
|
|
2005-09-07 06:18:53 +08:00
|
|
|
/*
|
2006-12-31 07:11:32 +08:00
|
|
|
* Select timing parameters for host.
|
2005-09-07 06:18:53 +08:00
|
|
|
*/
|
2006-12-31 07:11:32 +08:00
|
|
|
void mmc_set_timing(struct mmc_host *host, unsigned int timing)
|
2005-09-07 06:18:53 +08:00
|
|
|
{
|
2006-12-31 07:11:32 +08:00
|
|
|
host->ios.timing = timing;
|
|
|
|
mmc_set_ios(host);
|
2005-09-07 06:18:53 +08:00
|
|
|
}
|
|
|
|
|
2011-05-05 14:48:59 +08:00
|
|
|
/*
|
|
|
|
* Select appropriate driver type for host.
|
|
|
|
*/
|
|
|
|
void mmc_set_driver_type(struct mmc_host *host, unsigned int drv_type)
|
|
|
|
{
|
|
|
|
host->ios.drv_type = drv_type;
|
|
|
|
mmc_set_ios(host);
|
|
|
|
}
|
|
|
|
|
2015-02-06 20:12:55 +08:00
|
|
|
int mmc_select_drive_strength(struct mmc_card *card, unsigned int max_dtr,
|
|
|
|
int card_drv_type, int *drv_type)
|
|
|
|
{
|
|
|
|
struct mmc_host *host = card->host;
|
|
|
|
int host_drv_type = SD_DRIVER_TYPE_B;
|
|
|
|
|
|
|
|
*drv_type = 0;
|
|
|
|
|
|
|
|
if (!host->ops->select_drive_strength)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/* Use SD definition of driver strength for hosts */
|
|
|
|
if (host->caps & MMC_CAP_DRIVER_TYPE_A)
|
|
|
|
host_drv_type |= SD_DRIVER_TYPE_A;
|
|
|
|
|
|
|
|
if (host->caps & MMC_CAP_DRIVER_TYPE_C)
|
|
|
|
host_drv_type |= SD_DRIVER_TYPE_C;
|
|
|
|
|
|
|
|
if (host->caps & MMC_CAP_DRIVER_TYPE_D)
|
|
|
|
host_drv_type |= SD_DRIVER_TYPE_D;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The drive strength that the hardware can support
|
|
|
|
* depends on the board design. Pass the appropriate
|
|
|
|
* information and let the hardware specific code
|
|
|
|
* return what is possible given the options
|
|
|
|
*/
|
2015-10-02 16:56:11 +08:00
|
|
|
return host->ops->select_drive_strength(card, max_dtr,
|
|
|
|
host_drv_type,
|
|
|
|
card_drv_type,
|
|
|
|
drv_type);
|
2015-02-06 20:12:55 +08:00
|
|
|
}
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/*
|
2005-12-14 22:57:35 +08:00
|
|
|
* Apply power to the MMC stack. This is a two-stage process.
|
|
|
|
* First, we enable power to the card without the clock running.
|
|
|
|
* We then wait a bit for the power to stabilise. Finally,
|
|
|
|
* enable the bus drivers and clock to the card.
|
|
|
|
*
|
|
|
|
* We must _NOT_ enable the clock prior to power stablising.
|
|
|
|
*
|
|
|
|
* If a host does all the power sequencing itself, ignore the
|
|
|
|
* initial MMC_POWER_UP stage.
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
2013-09-12 20:36:53 +08:00
|
|
|
void mmc_power_up(struct mmc_host *host, u32 ocr)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2012-05-09 22:15:26 +08:00
|
|
|
if (host->ios.power_mode == MMC_POWER_ON)
|
|
|
|
return;
|
|
|
|
|
2014-11-28 21:38:36 +08:00
|
|
|
mmc_pwrseq_pre_power_on(host);
|
|
|
|
|
2013-09-12 20:36:53 +08:00
|
|
|
host->ios.vdd = fls(ocr) - 1;
|
2005-04-17 06:20:36 +08:00
|
|
|
host->ios.power_mode = MMC_POWER_UP;
|
2014-11-06 21:46:54 +08:00
|
|
|
/* Set initial state and call mmc_set_ios */
|
|
|
|
mmc_set_initial_state(host);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2018-04-06 03:24:15 +08:00
|
|
|
mmc_set_initial_signal_voltage(host);
|
mmc: core: reset signal voltage on power up
Add a call to mmc_set_signal_voltage() to set signal voltage to 3.3v in
mmc_power_up so that we do not need to touch signal voltage setting in
mmc/sd/sdio init functions and rescan function.
For mmc/sd cards, when doing a suspend/resume cycle, consider the unsafe
resume case, the card will lose its power and when powered on again, we
will set signal voltage to 3.3v in mmc_power_up before its resume function
gets called, which will re-init the card.
And for sdio cards, when doing a suspend/resume cycle, consider the unsafe
resume case, the card will either lose its power or not depending on if it
wants to wakeup the host. If power is not maintained, it is the same case as
mmc/sd cards. If power is maintained, mmc_power_up will not be called and
the card's signal voltage will remain at the last setting.
Signed-off-by: Aaron Lu <aaron.lu@amd.com>
Tested-by: Venkatraman S <svenkatr@ti.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
2012-07-10 16:55:37 +08:00
|
|
|
|
2007-09-20 00:38:50 +08:00
|
|
|
/*
|
|
|
|
* This delay should be sufficient to allow the power supply
|
|
|
|
* to reach the minimum voltage.
|
|
|
|
*/
|
mmc: core: add tunable delay waiting for power to be stable
The hard-coded 10ms delay in mmc_power_up came from
commit 79bccc5aefb4 ("mmc: increase power up delay"), which said "The TI
controller on Toshiba Tecra M5 needs more time to power up or the cards
will init incorrectly or not at all." But it's too engineering solution
for a special board but force all platforms to wait for that long time,
especially painful for mmc_power_up for eMMC when booting.
However, it's added since 2009, and we can't tell if other platforms
benefit from it. But in practise, the modern hardware are most likely to
have a stable power supply with 1ms after setting it for no matter PMIC
or discrete power. And more importnatly, most regulators implement the
callback of ->set_voltage_time_sel() for regulator core to wait for
specific period of time for the power supply to be stable, which means
once regulator_set_voltage_* return, the power should reach the the
minimum voltage that works for initialization. Of course, if there
are some other ways for host to power the card, we should allow them
to argue a suitable delay as well.
With this patch, we could assign the delay from firmware, or we could
assigne it via ->set_ios() callback from host drivers.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-05-08 09:04:20 +08:00
|
|
|
mmc_delay(host->ios.power_delay_ms);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2015-02-02 23:01:14 +08:00
|
|
|
mmc_pwrseq_post_power_on(host);
|
|
|
|
|
2010-09-06 09:37:19 +08:00
|
|
|
host->ios.clock = host->f_init;
|
2009-04-09 14:32:02 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
host->ios.power_mode = MMC_POWER_ON;
|
2006-05-05 01:22:51 +08:00
|
|
|
mmc_set_ios(host);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2007-09-20 00:38:50 +08:00
|
|
|
/*
|
|
|
|
* This delay must be at least 74 clock sizes, or 1 ms, or the
|
|
|
|
* time required to reach a stable voltage.
|
|
|
|
*/
|
mmc: core: add tunable delay waiting for power to be stable
The hard-coded 10ms delay in mmc_power_up came from
commit 79bccc5aefb4 ("mmc: increase power up delay"), which said "The TI
controller on Toshiba Tecra M5 needs more time to power up or the cards
will init incorrectly or not at all." But it's too engineering solution
for a special board but force all platforms to wait for that long time,
especially painful for mmc_power_up for eMMC when booting.
However, it's added since 2009, and we can't tell if other platforms
benefit from it. But in practise, the modern hardware are most likely to
have a stable power supply with 1ms after setting it for no matter PMIC
or discrete power. And more importnatly, most regulators implement the
callback of ->set_voltage_time_sel() for regulator core to wait for
specific period of time for the power supply to be stable, which means
once regulator_set_voltage_* return, the power should reach the the
minimum voltage that works for initialization. Of course, if there
are some other ways for host to power the card, we should allow them
to argue a suitable delay as well.
With this patch, we could assign the delay from firmware, or we could
assigne it via ->set_ios() callback from host drivers.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-05-08 09:04:20 +08:00
|
|
|
mmc_delay(host->ios.power_delay_ms);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2011-09-22 02:08:13 +08:00
|
|
|
void mmc_power_off(struct mmc_host *host)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2012-05-09 22:15:26 +08:00
|
|
|
if (host->ios.power_mode == MMC_POWER_OFF)
|
|
|
|
return;
|
|
|
|
|
2014-11-28 21:38:36 +08:00
|
|
|
mmc_pwrseq_power_off(host);
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
host->ios.clock = 0;
|
|
|
|
host->ios.vdd = 0;
|
2011-03-05 21:36:24 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
host->ios.power_mode = MMC_POWER_OFF;
|
2014-11-06 21:46:54 +08:00
|
|
|
/* Set initial state and call mmc_set_ios */
|
|
|
|
mmc_set_initial_state(host);
|
2011-08-18 20:23:48 +08:00
|
|
|
|
2011-09-07 17:22:09 +08:00
|
|
|
/*
|
|
|
|
* Some configurations, such as the 802.11 SDIO card in the OLPC
|
|
|
|
* XO-1.5, require a short delay after poweroff before the card
|
|
|
|
* can be successfully turned on again.
|
|
|
|
*/
|
|
|
|
mmc_delay(1);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2013-09-12 20:36:53 +08:00
|
|
|
void mmc_power_cycle(struct mmc_host *host, u32 ocr)
|
2013-01-28 22:08:25 +08:00
|
|
|
{
|
|
|
|
mmc_power_off(host);
|
|
|
|
/* Wait at least 1 ms according to SD spec */
|
|
|
|
mmc_delay(1);
|
2013-09-12 20:36:53 +08:00
|
|
|
mmc_power_up(host, ocr);
|
2013-01-28 22:08:25 +08:00
|
|
|
}
|
|
|
|
|
2007-07-25 06:40:58 +08:00
|
|
|
/*
|
|
|
|
* Cleanup when the last reference to the bus operator is dropped.
|
|
|
|
*/
|
2008-04-14 02:15:47 +08:00
|
|
|
static void __mmc_release_bus(struct mmc_host *host)
|
2007-07-25 06:40:58 +08:00
|
|
|
{
|
2016-11-02 15:26:16 +08:00
|
|
|
WARN_ON(!host->bus_dead);
|
2007-07-25 06:40:58 +08:00
|
|
|
|
|
|
|
host->bus_ops = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Increase reference count of bus operator
|
|
|
|
*/
|
|
|
|
static inline void mmc_bus_get(struct mmc_host *host)
|
|
|
|
{
|
|
|
|
unsigned long flags;
|
|
|
|
|
|
|
|
spin_lock_irqsave(&host->lock, flags);
|
|
|
|
host->bus_refs++;
|
|
|
|
spin_unlock_irqrestore(&host->lock, flags);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Decrease reference count of bus operator and free it if
|
|
|
|
* it is the last reference.
|
|
|
|
*/
|
|
|
|
static inline void mmc_bus_put(struct mmc_host *host)
|
|
|
|
{
|
|
|
|
unsigned long flags;
|
|
|
|
|
|
|
|
spin_lock_irqsave(&host->lock, flags);
|
|
|
|
host->bus_refs--;
|
|
|
|
if ((host->bus_refs == 0) && host->bus_ops)
|
|
|
|
__mmc_release_bus(host);
|
|
|
|
spin_unlock_irqrestore(&host->lock, flags);
|
|
|
|
}
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/*
|
2006-12-31 07:11:32 +08:00
|
|
|
* Assign a mmc bus handler to a host. Only one bus handler may control a
|
|
|
|
* host at any given time.
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
2006-12-31 07:11:32 +08:00
|
|
|
void mmc_attach_bus(struct mmc_host *host, const struct mmc_bus_ops *ops)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2006-12-31 07:11:32 +08:00
|
|
|
unsigned long flags;
|
2006-10-29 17:14:19 +08:00
|
|
|
|
2007-08-09 19:23:56 +08:00
|
|
|
WARN_ON(!host->claimed);
|
2006-10-21 18:35:02 +08:00
|
|
|
|
2006-12-31 07:11:32 +08:00
|
|
|
spin_lock_irqsave(&host->lock, flags);
|
2006-10-21 18:35:02 +08:00
|
|
|
|
2016-11-02 15:26:16 +08:00
|
|
|
WARN_ON(host->bus_ops);
|
|
|
|
WARN_ON(host->bus_refs);
|
2005-09-07 06:18:53 +08:00
|
|
|
|
2006-12-31 07:11:32 +08:00
|
|
|
host->bus_ops = ops;
|
|
|
|
host->bus_refs = 1;
|
|
|
|
host->bus_dead = 0;
|
2005-09-07 06:18:53 +08:00
|
|
|
|
2006-12-31 07:11:32 +08:00
|
|
|
spin_unlock_irqrestore(&host->lock, flags);
|
2005-09-07 06:18:53 +08:00
|
|
|
}
|
|
|
|
|
2006-12-31 07:11:32 +08:00
|
|
|
/*
|
2011-09-22 02:08:13 +08:00
|
|
|
* Remove the current bus handler from a host.
|
2006-12-31 07:11:32 +08:00
|
|
|
*/
|
|
|
|
void mmc_detach_bus(struct mmc_host *host)
|
2006-11-09 06:03:10 +08:00
|
|
|
{
|
2006-12-31 07:11:32 +08:00
|
|
|
unsigned long flags;
|
2006-11-09 06:03:10 +08:00
|
|
|
|
2007-08-09 19:23:56 +08:00
|
|
|
WARN_ON(!host->claimed);
|
|
|
|
WARN_ON(!host->bus_ops);
|
2007-02-18 19:07:47 +08:00
|
|
|
|
2006-12-31 07:11:32 +08:00
|
|
|
spin_lock_irqsave(&host->lock, flags);
|
2006-11-09 06:03:10 +08:00
|
|
|
|
2006-12-31 07:11:32 +08:00
|
|
|
host->bus_dead = 1;
|
2006-11-09 06:03:10 +08:00
|
|
|
|
2006-12-31 07:11:32 +08:00
|
|
|
spin_unlock_irqrestore(&host->lock, flags);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2006-12-31 07:11:32 +08:00
|
|
|
mmc_bus_put(host);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
mmc: core: Re-work HW reset for SDIO cards
It have turned out that it's not a good idea to unconditionally do a power
cycle and then to re-initialize the SDIO card, as currently done through
mmc_hw_reset() -> mmc_sdio_hw_reset(). This because there may be multiple
SDIO func drivers probed, who also shares the same SDIO card.
To address these scenarios, one may be tempted to use a notification
mechanism, as to allow the core to inform each of the probed func drivers,
about an ongoing HW reset. However, supporting such an operation from the
func driver point of view, may not be entirely trivial.
Therefore, let's use a more simplistic approach to solve the problem, by
instead forcing the card to be removed and re-detected, via scheduling a
rescan-work. In this way, we can rely on existing infrastructure, as the
func driver's ->remove() and ->probe() callbacks, becomes invoked to deal
with the cleanup and the re-initialization.
This solution may be considered as rather heavy, especially if a func
driver doesn't share its card with other func drivers. To address this,
let's keep the current immediate HW reset option as well, but run it only
when there is one func driver probed for the card.
Finally, to allow the caller of mmc_hw_reset(), to understand if the reset
is being asynchronously managed from a scheduled work, it returns 1
(propagated from mmc_sdio_hw_reset()). If the HW reset is executed
successfully and synchronously it returns 0, which maintains the existing
behaviour.
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Douglas Anderson <dianders@chromium.org>
Cc: stable@vger.kernel.org # v5.4+
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2019-10-17 21:25:36 +08:00
|
|
|
void _mmc_detect_change(struct mmc_host *host, unsigned long delay, bool cd_irq)
|
2013-09-20 17:02:35 +08:00
|
|
|
{
|
|
|
|
/*
|
2020-05-29 18:23:41 +08:00
|
|
|
* Prevent system sleep for 5s to allow user space to consume the
|
|
|
|
* corresponding uevent. This is especially useful, when CD irq is used
|
|
|
|
* as a system wakeup, but doesn't hurt in other cases.
|
2013-09-20 17:02:35 +08:00
|
|
|
*/
|
2020-05-29 18:23:41 +08:00
|
|
|
if (cd_irq && !(host->caps & MMC_CAP_NEEDS_POLL))
|
|
|
|
__pm_wakeup_event(host->ws, 5000);
|
2013-09-20 17:02:35 +08:00
|
|
|
|
|
|
|
host->detect_change = 1;
|
|
|
|
mmc_schedule_delayed_work(&host->detect, delay);
|
|
|
|
}
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/**
|
|
|
|
* mmc_detect_change - process change of state on a MMC socket
|
|
|
|
* @host: host which changed state.
|
2005-09-09 00:53:01 +08:00
|
|
|
* @delay: optional delay to wait before detection (jiffies)
|
2005-04-17 06:20:36 +08:00
|
|
|
*
|
2007-07-12 02:22:11 +08:00
|
|
|
* MMC drivers should call this when they detect a card has been
|
|
|
|
* inserted or removed. The MMC layer will confirm that any
|
|
|
|
* present card is still functional, and initialize any newly
|
|
|
|
* inserted.
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
2005-09-09 00:53:01 +08:00
|
|
|
void mmc_detect_change(struct mmc_host *host, unsigned long delay)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2013-09-20 17:02:35 +08:00
|
|
|
_mmc_detect_change(host, delay, true);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(mmc_detect_change);
|
|
|
|
|
mmc: add erase, secure erase, trim and secure trim operations
SD/MMC cards tend to support an erase operation. In addition, eMMC v4.4
cards can support secure erase, trim and secure trim operations that are
all variants of the basic erase command.
SD/MMC device attributes "erase_size" and "preferred_erase_size" have been
added.
"erase_size" is the minimum size, in bytes, of an erase operation. For
MMC, "erase_size" is the erase group size reported by the card. Note that
"erase_size" does not apply to trim or secure trim operations where the
minimum size is always one 512 byte sector. For SD, "erase_size" is 512
if the card is block-addressed, 0 otherwise.
SD/MMC cards can erase an arbitrarily large area up to and
including the whole card. When erasing a large area it may
be desirable to do it in smaller chunks for three reasons:
1. A single erase command will make all other I/O on the card
wait. This is not a problem if the whole card is being erased, but
erasing one partition will make I/O for another partition on the
same card wait for the duration of the erase - which could be a
several minutes.
2. To be able to inform the user of erase progress.
3. The erase timeout becomes too large to be very useful.
Because the erase timeout contains a margin which is multiplied by
the size of the erase area, the value can end up being several
minutes for large areas.
"erase_size" is not the most efficient unit to erase (especially for SD
where it is just one sector), hence "preferred_erase_size" provides a good
chunk size for erasing large areas.
For MMC, "preferred_erase_size" is the high-capacity erase size if a card
specifies one, otherwise it is based on the capacity of the card.
For SD, "preferred_erase_size" is the allocation unit size specified by
the card.
"preferred_erase_size" is in bytes.
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Cc: Kyungmin Park <kmpark@infradead.org>
Cc: Madhusudhan Chikkature <madhu.cr@ti.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Ben Gardiner <bengardiner@nanometrics.ca>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-12 05:17:46 +08:00
|
|
|
void mmc_init_erase(struct mmc_card *card)
|
|
|
|
{
|
|
|
|
unsigned int sz;
|
|
|
|
|
|
|
|
if (is_power_of_2(card->erase_size))
|
|
|
|
card->erase_shift = ffs(card->erase_size) - 1;
|
|
|
|
else
|
|
|
|
card->erase_shift = 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* It is possible to erase an arbitrarily large area of an SD or MMC
|
|
|
|
* card. That is not desirable because it can take a long time
|
|
|
|
* (minutes) potentially delaying more important I/O, and also the
|
|
|
|
* timeout calculations become increasingly hugely over-estimated.
|
|
|
|
* Consequently, 'pref_erase' is defined as a guide to limit erases
|
|
|
|
* to that size and alignment.
|
|
|
|
*
|
|
|
|
* For SD cards that define Allocation Unit size, limit erases to one
|
2016-06-04 00:08:52 +08:00
|
|
|
* Allocation Unit at a time.
|
|
|
|
* For MMC, have a stab at ai good value and for modern cards it will
|
|
|
|
* end up being 4MiB. Note that if the value is too small, it can end
|
|
|
|
* up taking longer to erase. Also note, erase_size is already set to
|
|
|
|
* High Capacity Erase Size if available when this function is called.
|
mmc: add erase, secure erase, trim and secure trim operations
SD/MMC cards tend to support an erase operation. In addition, eMMC v4.4
cards can support secure erase, trim and secure trim operations that are
all variants of the basic erase command.
SD/MMC device attributes "erase_size" and "preferred_erase_size" have been
added.
"erase_size" is the minimum size, in bytes, of an erase operation. For
MMC, "erase_size" is the erase group size reported by the card. Note that
"erase_size" does not apply to trim or secure trim operations where the
minimum size is always one 512 byte sector. For SD, "erase_size" is 512
if the card is block-addressed, 0 otherwise.
SD/MMC cards can erase an arbitrarily large area up to and
including the whole card. When erasing a large area it may
be desirable to do it in smaller chunks for three reasons:
1. A single erase command will make all other I/O on the card
wait. This is not a problem if the whole card is being erased, but
erasing one partition will make I/O for another partition on the
same card wait for the duration of the erase - which could be a
several minutes.
2. To be able to inform the user of erase progress.
3. The erase timeout becomes too large to be very useful.
Because the erase timeout contains a margin which is multiplied by
the size of the erase area, the value can end up being several
minutes for large areas.
"erase_size" is not the most efficient unit to erase (especially for SD
where it is just one sector), hence "preferred_erase_size" provides a good
chunk size for erasing large areas.
For MMC, "preferred_erase_size" is the high-capacity erase size if a card
specifies one, otherwise it is based on the capacity of the card.
For SD, "preferred_erase_size" is the allocation unit size specified by
the card.
"preferred_erase_size" is in bytes.
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Cc: Kyungmin Park <kmpark@infradead.org>
Cc: Madhusudhan Chikkature <madhu.cr@ti.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Ben Gardiner <bengardiner@nanometrics.ca>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-12 05:17:46 +08:00
|
|
|
*/
|
|
|
|
if (mmc_card_sd(card) && card->ssr.au) {
|
|
|
|
card->pref_erase = card->ssr.au;
|
|
|
|
card->erase_shift = ffs(card->ssr.au) - 1;
|
mmc: core: resolve divded by zero panic
With one special SD card, below divide by zero error observed:
...
[ 2.144300] divide error: 0000 [#1] PREEMPT SMP
[ 2.148860] Modules linked in:
[ 2.151898]
[ 2.152685] Set up 4031 stolen pages starting at 0x0001f000, GTT offset 0K
[ 2.157330] Set up 0 CI stolen pages starting at 0x00000000, GTT offset 131072K
[ 2.167581] Pid: 5, comm: kworker/u:0 Not tainted 3.0.8-138216-g974a2ab #1
[ 2.169506] [drm] PSB GTT mem manager ready, tt_start 4031, tt_size 28737 pages
[ 2.169906] [drm] SGX core id = 0x00000000
[ 2.169920] [drm] SGX core rev major = 0x00, minor = 0x00
[ 2.169934] [drm] SGX core rev maintenance = 0x00, designer = 0x00
[ 2.197370] Intel Corporation Medfield/iCDKB
[ 2.201716] EIP: 0060:[<c1697ca6>] EFLAGS: 00010246 CPU: 1
[ 2.207198] EIP is at mmc_init_erase+0x76/0x150
[ 2.211704] EAX: 00002000 EBX: dcd1b400 ECX: 00002000 EDX: 00000000
[ 2.217957] ESI: 00000000 EDI: dcd5c800 EBP: dd867e84 ESP: dd867e7c
[ 2.224214] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
[ 2.229605] Process kworker/u:0 (pid: 5, ti=dd866000 task=dd868000 task.ti=dd866000)
[ 2.237325] Stack:
[ 2.239322] dcd1b400 00000000 dd867eb0 c16a06da c1ab7c44 dd995aa8 00000003 00000000
[ 2.247054] 00000000 00000000 dcd5c800 00000000 dcd1b400 dd867ef8 c16a1012 c1698b00
[ 2.254785] 00000029 00000001 c194eb80 dcd5c9ec dd867e00 c1239b00 00000000 00000000
[ 2.262519] Call Trace:
[ 2.264975] [<c16a06da>] mmc_sd_setup_card+0x1da/0x4f0
[ 2.270183] [<c16a1012>] mmc_sd_init_card+0x192/0xc40
[ 2.275304] [<c1698b00>] ? __mmc_claim_host+0x160/0x160
[ 2.280610] [<c1239b00>] ? __schedule_bug+0x50/0x80
[ 2.285556] [<c16a1b89>] mmc_attach_sd+0xc9/0x230
[ 2.290333] [<c169b6ef>] mmc_rescan+0x25f/0x2c0
[ 2.294943] [<c1274223>] process_one_work+0x103/0x400
[ 2.300065] [<c12670fd>] ? mod_timer+0x1ad/0x3c0
[ 2.304756] [<c169b490>] ? mmc_suspend_host+0x1a0/0x1a0
[ 2.310056] [<c127502d>] worker_thread+0x12d/0x4a0
[ 2.314921] [<c18fcfbd>] ? preempt_schedule+0x2d/0x50
[ 2.320047] [<c1274f00[ 2.323976] ---[ end trace 5398ec2720494438 ]---
...
So, seems this bad SD card does not set valid value in related SSR / CSD register fields.
And then the driver will set card->erase_size to 0.
Then it triggered this divided by zero error when calculate card->pref_erase.
Submit this patch to fix the issue.
Signed-off-by: Yunpeng Gao <yunpeng.gao@intel.com>
Signed-off-by: Chuanxiao Dong <chuanxiao.dong@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2014-08-14 18:29:24 +08:00
|
|
|
} else if (card->erase_size) {
|
mmc: add erase, secure erase, trim and secure trim operations
SD/MMC cards tend to support an erase operation. In addition, eMMC v4.4
cards can support secure erase, trim and secure trim operations that are
all variants of the basic erase command.
SD/MMC device attributes "erase_size" and "preferred_erase_size" have been
added.
"erase_size" is the minimum size, in bytes, of an erase operation. For
MMC, "erase_size" is the erase group size reported by the card. Note that
"erase_size" does not apply to trim or secure trim operations where the
minimum size is always one 512 byte sector. For SD, "erase_size" is 512
if the card is block-addressed, 0 otherwise.
SD/MMC cards can erase an arbitrarily large area up to and
including the whole card. When erasing a large area it may
be desirable to do it in smaller chunks for three reasons:
1. A single erase command will make all other I/O on the card
wait. This is not a problem if the whole card is being erased, but
erasing one partition will make I/O for another partition on the
same card wait for the duration of the erase - which could be a
several minutes.
2. To be able to inform the user of erase progress.
3. The erase timeout becomes too large to be very useful.
Because the erase timeout contains a margin which is multiplied by
the size of the erase area, the value can end up being several
minutes for large areas.
"erase_size" is not the most efficient unit to erase (especially for SD
where it is just one sector), hence "preferred_erase_size" provides a good
chunk size for erasing large areas.
For MMC, "preferred_erase_size" is the high-capacity erase size if a card
specifies one, otherwise it is based on the capacity of the card.
For SD, "preferred_erase_size" is the allocation unit size specified by
the card.
"preferred_erase_size" is in bytes.
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Cc: Kyungmin Park <kmpark@infradead.org>
Cc: Madhusudhan Chikkature <madhu.cr@ti.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Ben Gardiner <bengardiner@nanometrics.ca>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-12 05:17:46 +08:00
|
|
|
sz = (card->csd.capacity << (card->csd.read_blkbits - 9)) >> 11;
|
|
|
|
if (sz < 128)
|
|
|
|
card->pref_erase = 512 * 1024 / 512;
|
|
|
|
else if (sz < 512)
|
|
|
|
card->pref_erase = 1024 * 1024 / 512;
|
|
|
|
else if (sz < 1024)
|
|
|
|
card->pref_erase = 2 * 1024 * 1024 / 512;
|
|
|
|
else
|
|
|
|
card->pref_erase = 4 * 1024 * 1024 / 512;
|
|
|
|
if (card->pref_erase < card->erase_size)
|
|
|
|
card->pref_erase = card->erase_size;
|
|
|
|
else {
|
|
|
|
sz = card->pref_erase % card->erase_size;
|
|
|
|
if (sz)
|
|
|
|
card->pref_erase += card->erase_size - sz;
|
|
|
|
}
|
mmc: core: resolve divded by zero panic
With one special SD card, below divide by zero error observed:
...
[ 2.144300] divide error: 0000 [#1] PREEMPT SMP
[ 2.148860] Modules linked in:
[ 2.151898]
[ 2.152685] Set up 4031 stolen pages starting at 0x0001f000, GTT offset 0K
[ 2.157330] Set up 0 CI stolen pages starting at 0x00000000, GTT offset 131072K
[ 2.167581] Pid: 5, comm: kworker/u:0 Not tainted 3.0.8-138216-g974a2ab #1
[ 2.169506] [drm] PSB GTT mem manager ready, tt_start 4031, tt_size 28737 pages
[ 2.169906] [drm] SGX core id = 0x00000000
[ 2.169920] [drm] SGX core rev major = 0x00, minor = 0x00
[ 2.169934] [drm] SGX core rev maintenance = 0x00, designer = 0x00
[ 2.197370] Intel Corporation Medfield/iCDKB
[ 2.201716] EIP: 0060:[<c1697ca6>] EFLAGS: 00010246 CPU: 1
[ 2.207198] EIP is at mmc_init_erase+0x76/0x150
[ 2.211704] EAX: 00002000 EBX: dcd1b400 ECX: 00002000 EDX: 00000000
[ 2.217957] ESI: 00000000 EDI: dcd5c800 EBP: dd867e84 ESP: dd867e7c
[ 2.224214] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
[ 2.229605] Process kworker/u:0 (pid: 5, ti=dd866000 task=dd868000 task.ti=dd866000)
[ 2.237325] Stack:
[ 2.239322] dcd1b400 00000000 dd867eb0 c16a06da c1ab7c44 dd995aa8 00000003 00000000
[ 2.247054] 00000000 00000000 dcd5c800 00000000 dcd1b400 dd867ef8 c16a1012 c1698b00
[ 2.254785] 00000029 00000001 c194eb80 dcd5c9ec dd867e00 c1239b00 00000000 00000000
[ 2.262519] Call Trace:
[ 2.264975] [<c16a06da>] mmc_sd_setup_card+0x1da/0x4f0
[ 2.270183] [<c16a1012>] mmc_sd_init_card+0x192/0xc40
[ 2.275304] [<c1698b00>] ? __mmc_claim_host+0x160/0x160
[ 2.280610] [<c1239b00>] ? __schedule_bug+0x50/0x80
[ 2.285556] [<c16a1b89>] mmc_attach_sd+0xc9/0x230
[ 2.290333] [<c169b6ef>] mmc_rescan+0x25f/0x2c0
[ 2.294943] [<c1274223>] process_one_work+0x103/0x400
[ 2.300065] [<c12670fd>] ? mod_timer+0x1ad/0x3c0
[ 2.304756] [<c169b490>] ? mmc_suspend_host+0x1a0/0x1a0
[ 2.310056] [<c127502d>] worker_thread+0x12d/0x4a0
[ 2.314921] [<c18fcfbd>] ? preempt_schedule+0x2d/0x50
[ 2.320047] [<c1274f00[ 2.323976] ---[ end trace 5398ec2720494438 ]---
...
So, seems this bad SD card does not set valid value in related SSR / CSD register fields.
And then the driver will set card->erase_size to 0.
Then it triggered this divided by zero error when calculate card->pref_erase.
Submit this patch to fix the issue.
Signed-off-by: Yunpeng Gao <yunpeng.gao@intel.com>
Signed-off-by: Chuanxiao Dong <chuanxiao.dong@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2014-08-14 18:29:24 +08:00
|
|
|
} else
|
|
|
|
card->pref_erase = 0;
|
mmc: add erase, secure erase, trim and secure trim operations
SD/MMC cards tend to support an erase operation. In addition, eMMC v4.4
cards can support secure erase, trim and secure trim operations that are
all variants of the basic erase command.
SD/MMC device attributes "erase_size" and "preferred_erase_size" have been
added.
"erase_size" is the minimum size, in bytes, of an erase operation. For
MMC, "erase_size" is the erase group size reported by the card. Note that
"erase_size" does not apply to trim or secure trim operations where the
minimum size is always one 512 byte sector. For SD, "erase_size" is 512
if the card is block-addressed, 0 otherwise.
SD/MMC cards can erase an arbitrarily large area up to and
including the whole card. When erasing a large area it may
be desirable to do it in smaller chunks for three reasons:
1. A single erase command will make all other I/O on the card
wait. This is not a problem if the whole card is being erased, but
erasing one partition will make I/O for another partition on the
same card wait for the duration of the erase - which could be a
several minutes.
2. To be able to inform the user of erase progress.
3. The erase timeout becomes too large to be very useful.
Because the erase timeout contains a margin which is multiplied by
the size of the erase area, the value can end up being several
minutes for large areas.
"erase_size" is not the most efficient unit to erase (especially for SD
where it is just one sector), hence "preferred_erase_size" provides a good
chunk size for erasing large areas.
For MMC, "preferred_erase_size" is the high-capacity erase size if a card
specifies one, otherwise it is based on the capacity of the card.
For SD, "preferred_erase_size" is the allocation unit size specified by
the card.
"preferred_erase_size" is in bytes.
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Cc: Kyungmin Park <kmpark@infradead.org>
Cc: Madhusudhan Chikkature <madhu.cr@ti.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Ben Gardiner <bengardiner@nanometrics.ca>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-12 05:17:46 +08:00
|
|
|
}
|
|
|
|
|
2011-04-12 05:13:41 +08:00
|
|
|
static unsigned int mmc_mmc_erase_timeout(struct mmc_card *card,
|
|
|
|
unsigned int arg, unsigned int qty)
|
mmc: add erase, secure erase, trim and secure trim operations
SD/MMC cards tend to support an erase operation. In addition, eMMC v4.4
cards can support secure erase, trim and secure trim operations that are
all variants of the basic erase command.
SD/MMC device attributes "erase_size" and "preferred_erase_size" have been
added.
"erase_size" is the minimum size, in bytes, of an erase operation. For
MMC, "erase_size" is the erase group size reported by the card. Note that
"erase_size" does not apply to trim or secure trim operations where the
minimum size is always one 512 byte sector. For SD, "erase_size" is 512
if the card is block-addressed, 0 otherwise.
SD/MMC cards can erase an arbitrarily large area up to and
including the whole card. When erasing a large area it may
be desirable to do it in smaller chunks for three reasons:
1. A single erase command will make all other I/O on the card
wait. This is not a problem if the whole card is being erased, but
erasing one partition will make I/O for another partition on the
same card wait for the duration of the erase - which could be a
several minutes.
2. To be able to inform the user of erase progress.
3. The erase timeout becomes too large to be very useful.
Because the erase timeout contains a margin which is multiplied by
the size of the erase area, the value can end up being several
minutes for large areas.
"erase_size" is not the most efficient unit to erase (especially for SD
where it is just one sector), hence "preferred_erase_size" provides a good
chunk size for erasing large areas.
For MMC, "preferred_erase_size" is the high-capacity erase size if a card
specifies one, otherwise it is based on the capacity of the card.
For SD, "preferred_erase_size" is the allocation unit size specified by
the card.
"preferred_erase_size" is in bytes.
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Cc: Kyungmin Park <kmpark@infradead.org>
Cc: Madhusudhan Chikkature <madhu.cr@ti.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Ben Gardiner <bengardiner@nanometrics.ca>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-12 05:17:46 +08:00
|
|
|
{
|
|
|
|
unsigned int erase_timeout;
|
|
|
|
|
2012-04-05 19:45:47 +08:00
|
|
|
if (arg == MMC_DISCARD_ARG ||
|
|
|
|
(arg == MMC_TRIM_ARG && card->ext_csd.rev >= 6)) {
|
|
|
|
erase_timeout = card->ext_csd.trim_timeout;
|
|
|
|
} else if (card->ext_csd.erase_group_def & 1) {
|
mmc: add erase, secure erase, trim and secure trim operations
SD/MMC cards tend to support an erase operation. In addition, eMMC v4.4
cards can support secure erase, trim and secure trim operations that are
all variants of the basic erase command.
SD/MMC device attributes "erase_size" and "preferred_erase_size" have been
added.
"erase_size" is the minimum size, in bytes, of an erase operation. For
MMC, "erase_size" is the erase group size reported by the card. Note that
"erase_size" does not apply to trim or secure trim operations where the
minimum size is always one 512 byte sector. For SD, "erase_size" is 512
if the card is block-addressed, 0 otherwise.
SD/MMC cards can erase an arbitrarily large area up to and
including the whole card. When erasing a large area it may
be desirable to do it in smaller chunks for three reasons:
1. A single erase command will make all other I/O on the card
wait. This is not a problem if the whole card is being erased, but
erasing one partition will make I/O for another partition on the
same card wait for the duration of the erase - which could be a
several minutes.
2. To be able to inform the user of erase progress.
3. The erase timeout becomes too large to be very useful.
Because the erase timeout contains a margin which is multiplied by
the size of the erase area, the value can end up being several
minutes for large areas.
"erase_size" is not the most efficient unit to erase (especially for SD
where it is just one sector), hence "preferred_erase_size" provides a good
chunk size for erasing large areas.
For MMC, "preferred_erase_size" is the high-capacity erase size if a card
specifies one, otherwise it is based on the capacity of the card.
For SD, "preferred_erase_size" is the allocation unit size specified by
the card.
"preferred_erase_size" is in bytes.
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Cc: Kyungmin Park <kmpark@infradead.org>
Cc: Madhusudhan Chikkature <madhu.cr@ti.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Ben Gardiner <bengardiner@nanometrics.ca>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-12 05:17:46 +08:00
|
|
|
/* High Capacity Erase Group Size uses HC timeouts */
|
|
|
|
if (arg == MMC_TRIM_ARG)
|
|
|
|
erase_timeout = card->ext_csd.trim_timeout;
|
|
|
|
else
|
|
|
|
erase_timeout = card->ext_csd.hc_erase_timeout;
|
|
|
|
} else {
|
|
|
|
/* CSD Erase Group Size uses write timeout */
|
|
|
|
unsigned int mult = (10 << card->csd.r2w_factor);
|
2017-08-02 11:12:42 +08:00
|
|
|
unsigned int timeout_clks = card->csd.taac_clks * mult;
|
mmc: add erase, secure erase, trim and secure trim operations
SD/MMC cards tend to support an erase operation. In addition, eMMC v4.4
cards can support secure erase, trim and secure trim operations that are
all variants of the basic erase command.
SD/MMC device attributes "erase_size" and "preferred_erase_size" have been
added.
"erase_size" is the minimum size, in bytes, of an erase operation. For
MMC, "erase_size" is the erase group size reported by the card. Note that
"erase_size" does not apply to trim or secure trim operations where the
minimum size is always one 512 byte sector. For SD, "erase_size" is 512
if the card is block-addressed, 0 otherwise.
SD/MMC cards can erase an arbitrarily large area up to and
including the whole card. When erasing a large area it may
be desirable to do it in smaller chunks for three reasons:
1. A single erase command will make all other I/O on the card
wait. This is not a problem if the whole card is being erased, but
erasing one partition will make I/O for another partition on the
same card wait for the duration of the erase - which could be a
several minutes.
2. To be able to inform the user of erase progress.
3. The erase timeout becomes too large to be very useful.
Because the erase timeout contains a margin which is multiplied by
the size of the erase area, the value can end up being several
minutes for large areas.
"erase_size" is not the most efficient unit to erase (especially for SD
where it is just one sector), hence "preferred_erase_size" provides a good
chunk size for erasing large areas.
For MMC, "preferred_erase_size" is the high-capacity erase size if a card
specifies one, otherwise it is based on the capacity of the card.
For SD, "preferred_erase_size" is the allocation unit size specified by
the card.
"preferred_erase_size" is in bytes.
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Cc: Kyungmin Park <kmpark@infradead.org>
Cc: Madhusudhan Chikkature <madhu.cr@ti.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Ben Gardiner <bengardiner@nanometrics.ca>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-12 05:17:46 +08:00
|
|
|
unsigned int timeout_us;
|
|
|
|
|
2017-08-02 11:12:42 +08:00
|
|
|
/* Avoid overflow: e.g. taac_ns=80000000 mult=1280 */
|
|
|
|
if (card->csd.taac_ns < 1000000)
|
|
|
|
timeout_us = (card->csd.taac_ns * mult) / 1000;
|
mmc: add erase, secure erase, trim and secure trim operations
SD/MMC cards tend to support an erase operation. In addition, eMMC v4.4
cards can support secure erase, trim and secure trim operations that are
all variants of the basic erase command.
SD/MMC device attributes "erase_size" and "preferred_erase_size" have been
added.
"erase_size" is the minimum size, in bytes, of an erase operation. For
MMC, "erase_size" is the erase group size reported by the card. Note that
"erase_size" does not apply to trim or secure trim operations where the
minimum size is always one 512 byte sector. For SD, "erase_size" is 512
if the card is block-addressed, 0 otherwise.
SD/MMC cards can erase an arbitrarily large area up to and
including the whole card. When erasing a large area it may
be desirable to do it in smaller chunks for three reasons:
1. A single erase command will make all other I/O on the card
wait. This is not a problem if the whole card is being erased, but
erasing one partition will make I/O for another partition on the
same card wait for the duration of the erase - which could be a
several minutes.
2. To be able to inform the user of erase progress.
3. The erase timeout becomes too large to be very useful.
Because the erase timeout contains a margin which is multiplied by
the size of the erase area, the value can end up being several
minutes for large areas.
"erase_size" is not the most efficient unit to erase (especially for SD
where it is just one sector), hence "preferred_erase_size" provides a good
chunk size for erasing large areas.
For MMC, "preferred_erase_size" is the high-capacity erase size if a card
specifies one, otherwise it is based on the capacity of the card.
For SD, "preferred_erase_size" is the allocation unit size specified by
the card.
"preferred_erase_size" is in bytes.
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Cc: Kyungmin Park <kmpark@infradead.org>
Cc: Madhusudhan Chikkature <madhu.cr@ti.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Ben Gardiner <bengardiner@nanometrics.ca>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-12 05:17:46 +08:00
|
|
|
else
|
2017-08-02 11:12:42 +08:00
|
|
|
timeout_us = (card->csd.taac_ns / 1000) * mult;
|
mmc: add erase, secure erase, trim and secure trim operations
SD/MMC cards tend to support an erase operation. In addition, eMMC v4.4
cards can support secure erase, trim and secure trim operations that are
all variants of the basic erase command.
SD/MMC device attributes "erase_size" and "preferred_erase_size" have been
added.
"erase_size" is the minimum size, in bytes, of an erase operation. For
MMC, "erase_size" is the erase group size reported by the card. Note that
"erase_size" does not apply to trim or secure trim operations where the
minimum size is always one 512 byte sector. For SD, "erase_size" is 512
if the card is block-addressed, 0 otherwise.
SD/MMC cards can erase an arbitrarily large area up to and
including the whole card. When erasing a large area it may
be desirable to do it in smaller chunks for three reasons:
1. A single erase command will make all other I/O on the card
wait. This is not a problem if the whole card is being erased, but
erasing one partition will make I/O for another partition on the
same card wait for the duration of the erase - which could be a
several minutes.
2. To be able to inform the user of erase progress.
3. The erase timeout becomes too large to be very useful.
Because the erase timeout contains a margin which is multiplied by
the size of the erase area, the value can end up being several
minutes for large areas.
"erase_size" is not the most efficient unit to erase (especially for SD
where it is just one sector), hence "preferred_erase_size" provides a good
chunk size for erasing large areas.
For MMC, "preferred_erase_size" is the high-capacity erase size if a card
specifies one, otherwise it is based on the capacity of the card.
For SD, "preferred_erase_size" is the allocation unit size specified by
the card.
"preferred_erase_size" is in bytes.
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Cc: Kyungmin Park <kmpark@infradead.org>
Cc: Madhusudhan Chikkature <madhu.cr@ti.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Ben Gardiner <bengardiner@nanometrics.ca>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-12 05:17:46 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* ios.clock is only a target. The real clock rate might be
|
|
|
|
* less but not that much less, so fudge it by multiplying by 2.
|
|
|
|
*/
|
|
|
|
timeout_clks <<= 1;
|
|
|
|
timeout_us += (timeout_clks * 1000) /
|
2015-10-02 16:56:11 +08:00
|
|
|
(card->host->ios.clock / 1000);
|
mmc: add erase, secure erase, trim and secure trim operations
SD/MMC cards tend to support an erase operation. In addition, eMMC v4.4
cards can support secure erase, trim and secure trim operations that are
all variants of the basic erase command.
SD/MMC device attributes "erase_size" and "preferred_erase_size" have been
added.
"erase_size" is the minimum size, in bytes, of an erase operation. For
MMC, "erase_size" is the erase group size reported by the card. Note that
"erase_size" does not apply to trim or secure trim operations where the
minimum size is always one 512 byte sector. For SD, "erase_size" is 512
if the card is block-addressed, 0 otherwise.
SD/MMC cards can erase an arbitrarily large area up to and
including the whole card. When erasing a large area it may
be desirable to do it in smaller chunks for three reasons:
1. A single erase command will make all other I/O on the card
wait. This is not a problem if the whole card is being erased, but
erasing one partition will make I/O for another partition on the
same card wait for the duration of the erase - which could be a
several minutes.
2. To be able to inform the user of erase progress.
3. The erase timeout becomes too large to be very useful.
Because the erase timeout contains a margin which is multiplied by
the size of the erase area, the value can end up being several
minutes for large areas.
"erase_size" is not the most efficient unit to erase (especially for SD
where it is just one sector), hence "preferred_erase_size" provides a good
chunk size for erasing large areas.
For MMC, "preferred_erase_size" is the high-capacity erase size if a card
specifies one, otherwise it is based on the capacity of the card.
For SD, "preferred_erase_size" is the allocation unit size specified by
the card.
"preferred_erase_size" is in bytes.
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Cc: Kyungmin Park <kmpark@infradead.org>
Cc: Madhusudhan Chikkature <madhu.cr@ti.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Ben Gardiner <bengardiner@nanometrics.ca>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-12 05:17:46 +08:00
|
|
|
|
|
|
|
erase_timeout = timeout_us / 1000;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Theoretically, the calculation could underflow so round up
|
|
|
|
* to 1ms in that case.
|
|
|
|
*/
|
|
|
|
if (!erase_timeout)
|
|
|
|
erase_timeout = 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Multiplier for secure operations */
|
|
|
|
if (arg & MMC_SECURE_ARGS) {
|
|
|
|
if (arg == MMC_SECURE_ERASE_ARG)
|
|
|
|
erase_timeout *= card->ext_csd.sec_erase_mult;
|
|
|
|
else
|
|
|
|
erase_timeout *= card->ext_csd.sec_trim_mult;
|
|
|
|
}
|
|
|
|
|
|
|
|
erase_timeout *= qty;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Ensure at least a 1 second timeout for SPI as per
|
|
|
|
* 'mmc_set_data_timeout()'
|
|
|
|
*/
|
|
|
|
if (mmc_host_is_spi(card->host) && erase_timeout < 1000)
|
|
|
|
erase_timeout = 1000;
|
|
|
|
|
2011-04-12 05:13:41 +08:00
|
|
|
return erase_timeout;
|
mmc: add erase, secure erase, trim and secure trim operations
SD/MMC cards tend to support an erase operation. In addition, eMMC v4.4
cards can support secure erase, trim and secure trim operations that are
all variants of the basic erase command.
SD/MMC device attributes "erase_size" and "preferred_erase_size" have been
added.
"erase_size" is the minimum size, in bytes, of an erase operation. For
MMC, "erase_size" is the erase group size reported by the card. Note that
"erase_size" does not apply to trim or secure trim operations where the
minimum size is always one 512 byte sector. For SD, "erase_size" is 512
if the card is block-addressed, 0 otherwise.
SD/MMC cards can erase an arbitrarily large area up to and
including the whole card. When erasing a large area it may
be desirable to do it in smaller chunks for three reasons:
1. A single erase command will make all other I/O on the card
wait. This is not a problem if the whole card is being erased, but
erasing one partition will make I/O for another partition on the
same card wait for the duration of the erase - which could be a
several minutes.
2. To be able to inform the user of erase progress.
3. The erase timeout becomes too large to be very useful.
Because the erase timeout contains a margin which is multiplied by
the size of the erase area, the value can end up being several
minutes for large areas.
"erase_size" is not the most efficient unit to erase (especially for SD
where it is just one sector), hence "preferred_erase_size" provides a good
chunk size for erasing large areas.
For MMC, "preferred_erase_size" is the high-capacity erase size if a card
specifies one, otherwise it is based on the capacity of the card.
For SD, "preferred_erase_size" is the allocation unit size specified by
the card.
"preferred_erase_size" is in bytes.
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Cc: Kyungmin Park <kmpark@infradead.org>
Cc: Madhusudhan Chikkature <madhu.cr@ti.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Ben Gardiner <bengardiner@nanometrics.ca>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-12 05:17:46 +08:00
|
|
|
}
|
|
|
|
|
2011-04-12 05:13:41 +08:00
|
|
|
static unsigned int mmc_sd_erase_timeout(struct mmc_card *card,
|
|
|
|
unsigned int arg,
|
|
|
|
unsigned int qty)
|
mmc: add erase, secure erase, trim and secure trim operations
SD/MMC cards tend to support an erase operation. In addition, eMMC v4.4
cards can support secure erase, trim and secure trim operations that are
all variants of the basic erase command.
SD/MMC device attributes "erase_size" and "preferred_erase_size" have been
added.
"erase_size" is the minimum size, in bytes, of an erase operation. For
MMC, "erase_size" is the erase group size reported by the card. Note that
"erase_size" does not apply to trim or secure trim operations where the
minimum size is always one 512 byte sector. For SD, "erase_size" is 512
if the card is block-addressed, 0 otherwise.
SD/MMC cards can erase an arbitrarily large area up to and
including the whole card. When erasing a large area it may
be desirable to do it in smaller chunks for three reasons:
1. A single erase command will make all other I/O on the card
wait. This is not a problem if the whole card is being erased, but
erasing one partition will make I/O for another partition on the
same card wait for the duration of the erase - which could be a
several minutes.
2. To be able to inform the user of erase progress.
3. The erase timeout becomes too large to be very useful.
Because the erase timeout contains a margin which is multiplied by
the size of the erase area, the value can end up being several
minutes for large areas.
"erase_size" is not the most efficient unit to erase (especially for SD
where it is just one sector), hence "preferred_erase_size" provides a good
chunk size for erasing large areas.
For MMC, "preferred_erase_size" is the high-capacity erase size if a card
specifies one, otherwise it is based on the capacity of the card.
For SD, "preferred_erase_size" is the allocation unit size specified by
the card.
"preferred_erase_size" is in bytes.
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Cc: Kyungmin Park <kmpark@infradead.org>
Cc: Madhusudhan Chikkature <madhu.cr@ti.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Ben Gardiner <bengardiner@nanometrics.ca>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-12 05:17:46 +08:00
|
|
|
{
|
2011-04-12 05:13:41 +08:00
|
|
|
unsigned int erase_timeout;
|
|
|
|
|
2019-02-26 23:10:25 +08:00
|
|
|
/* for DISCARD none of the below calculation applies.
|
|
|
|
* the busy timeout is 250msec per discard command.
|
|
|
|
*/
|
|
|
|
if (arg == SD_DISCARD_ARG)
|
|
|
|
return SD_DISCARD_TIMEOUT_MS;
|
|
|
|
|
mmc: add erase, secure erase, trim and secure trim operations
SD/MMC cards tend to support an erase operation. In addition, eMMC v4.4
cards can support secure erase, trim and secure trim operations that are
all variants of the basic erase command.
SD/MMC device attributes "erase_size" and "preferred_erase_size" have been
added.
"erase_size" is the minimum size, in bytes, of an erase operation. For
MMC, "erase_size" is the erase group size reported by the card. Note that
"erase_size" does not apply to trim or secure trim operations where the
minimum size is always one 512 byte sector. For SD, "erase_size" is 512
if the card is block-addressed, 0 otherwise.
SD/MMC cards can erase an arbitrarily large area up to and
including the whole card. When erasing a large area it may
be desirable to do it in smaller chunks for three reasons:
1. A single erase command will make all other I/O on the card
wait. This is not a problem if the whole card is being erased, but
erasing one partition will make I/O for another partition on the
same card wait for the duration of the erase - which could be a
several minutes.
2. To be able to inform the user of erase progress.
3. The erase timeout becomes too large to be very useful.
Because the erase timeout contains a margin which is multiplied by
the size of the erase area, the value can end up being several
minutes for large areas.
"erase_size" is not the most efficient unit to erase (especially for SD
where it is just one sector), hence "preferred_erase_size" provides a good
chunk size for erasing large areas.
For MMC, "preferred_erase_size" is the high-capacity erase size if a card
specifies one, otherwise it is based on the capacity of the card.
For SD, "preferred_erase_size" is the allocation unit size specified by
the card.
"preferred_erase_size" is in bytes.
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Cc: Kyungmin Park <kmpark@infradead.org>
Cc: Madhusudhan Chikkature <madhu.cr@ti.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Ben Gardiner <bengardiner@nanometrics.ca>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-12 05:17:46 +08:00
|
|
|
if (card->ssr.erase_timeout) {
|
|
|
|
/* Erase timeout specified in SD Status Register (SSR) */
|
2011-04-12 05:13:41 +08:00
|
|
|
erase_timeout = card->ssr.erase_timeout * qty +
|
|
|
|
card->ssr.erase_offset;
|
mmc: add erase, secure erase, trim and secure trim operations
SD/MMC cards tend to support an erase operation. In addition, eMMC v4.4
cards can support secure erase, trim and secure trim operations that are
all variants of the basic erase command.
SD/MMC device attributes "erase_size" and "preferred_erase_size" have been
added.
"erase_size" is the minimum size, in bytes, of an erase operation. For
MMC, "erase_size" is the erase group size reported by the card. Note that
"erase_size" does not apply to trim or secure trim operations where the
minimum size is always one 512 byte sector. For SD, "erase_size" is 512
if the card is block-addressed, 0 otherwise.
SD/MMC cards can erase an arbitrarily large area up to and
including the whole card. When erasing a large area it may
be desirable to do it in smaller chunks for three reasons:
1. A single erase command will make all other I/O on the card
wait. This is not a problem if the whole card is being erased, but
erasing one partition will make I/O for another partition on the
same card wait for the duration of the erase - which could be a
several minutes.
2. To be able to inform the user of erase progress.
3. The erase timeout becomes too large to be very useful.
Because the erase timeout contains a margin which is multiplied by
the size of the erase area, the value can end up being several
minutes for large areas.
"erase_size" is not the most efficient unit to erase (especially for SD
where it is just one sector), hence "preferred_erase_size" provides a good
chunk size for erasing large areas.
For MMC, "preferred_erase_size" is the high-capacity erase size if a card
specifies one, otherwise it is based on the capacity of the card.
For SD, "preferred_erase_size" is the allocation unit size specified by
the card.
"preferred_erase_size" is in bytes.
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Cc: Kyungmin Park <kmpark@infradead.org>
Cc: Madhusudhan Chikkature <madhu.cr@ti.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Ben Gardiner <bengardiner@nanometrics.ca>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-12 05:17:46 +08:00
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* Erase timeout not specified in SD Status Register (SSR) so
|
|
|
|
* use 250ms per write block.
|
|
|
|
*/
|
2011-04-12 05:13:41 +08:00
|
|
|
erase_timeout = 250 * qty;
|
mmc: add erase, secure erase, trim and secure trim operations
SD/MMC cards tend to support an erase operation. In addition, eMMC v4.4
cards can support secure erase, trim and secure trim operations that are
all variants of the basic erase command.
SD/MMC device attributes "erase_size" and "preferred_erase_size" have been
added.
"erase_size" is the minimum size, in bytes, of an erase operation. For
MMC, "erase_size" is the erase group size reported by the card. Note that
"erase_size" does not apply to trim or secure trim operations where the
minimum size is always one 512 byte sector. For SD, "erase_size" is 512
if the card is block-addressed, 0 otherwise.
SD/MMC cards can erase an arbitrarily large area up to and
including the whole card. When erasing a large area it may
be desirable to do it in smaller chunks for three reasons:
1. A single erase command will make all other I/O on the card
wait. This is not a problem if the whole card is being erased, but
erasing one partition will make I/O for another partition on the
same card wait for the duration of the erase - which could be a
several minutes.
2. To be able to inform the user of erase progress.
3. The erase timeout becomes too large to be very useful.
Because the erase timeout contains a margin which is multiplied by
the size of the erase area, the value can end up being several
minutes for large areas.
"erase_size" is not the most efficient unit to erase (especially for SD
where it is just one sector), hence "preferred_erase_size" provides a good
chunk size for erasing large areas.
For MMC, "preferred_erase_size" is the high-capacity erase size if a card
specifies one, otherwise it is based on the capacity of the card.
For SD, "preferred_erase_size" is the allocation unit size specified by
the card.
"preferred_erase_size" is in bytes.
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Cc: Kyungmin Park <kmpark@infradead.org>
Cc: Madhusudhan Chikkature <madhu.cr@ti.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Ben Gardiner <bengardiner@nanometrics.ca>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-12 05:17:46 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Must not be less than 1 second */
|
2011-04-12 05:13:41 +08:00
|
|
|
if (erase_timeout < 1000)
|
|
|
|
erase_timeout = 1000;
|
|
|
|
|
|
|
|
return erase_timeout;
|
mmc: add erase, secure erase, trim and secure trim operations
SD/MMC cards tend to support an erase operation. In addition, eMMC v4.4
cards can support secure erase, trim and secure trim operations that are
all variants of the basic erase command.
SD/MMC device attributes "erase_size" and "preferred_erase_size" have been
added.
"erase_size" is the minimum size, in bytes, of an erase operation. For
MMC, "erase_size" is the erase group size reported by the card. Note that
"erase_size" does not apply to trim or secure trim operations where the
minimum size is always one 512 byte sector. For SD, "erase_size" is 512
if the card is block-addressed, 0 otherwise.
SD/MMC cards can erase an arbitrarily large area up to and
including the whole card. When erasing a large area it may
be desirable to do it in smaller chunks for three reasons:
1. A single erase command will make all other I/O on the card
wait. This is not a problem if the whole card is being erased, but
erasing one partition will make I/O for another partition on the
same card wait for the duration of the erase - which could be a
several minutes.
2. To be able to inform the user of erase progress.
3. The erase timeout becomes too large to be very useful.
Because the erase timeout contains a margin which is multiplied by
the size of the erase area, the value can end up being several
minutes for large areas.
"erase_size" is not the most efficient unit to erase (especially for SD
where it is just one sector), hence "preferred_erase_size" provides a good
chunk size for erasing large areas.
For MMC, "preferred_erase_size" is the high-capacity erase size if a card
specifies one, otherwise it is based on the capacity of the card.
For SD, "preferred_erase_size" is the allocation unit size specified by
the card.
"preferred_erase_size" is in bytes.
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Cc: Kyungmin Park <kmpark@infradead.org>
Cc: Madhusudhan Chikkature <madhu.cr@ti.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Ben Gardiner <bengardiner@nanometrics.ca>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-12 05:17:46 +08:00
|
|
|
}
|
|
|
|
|
2011-04-12 05:13:41 +08:00
|
|
|
static unsigned int mmc_erase_timeout(struct mmc_card *card,
|
|
|
|
unsigned int arg,
|
|
|
|
unsigned int qty)
|
mmc: add erase, secure erase, trim and secure trim operations
SD/MMC cards tend to support an erase operation. In addition, eMMC v4.4
cards can support secure erase, trim and secure trim operations that are
all variants of the basic erase command.
SD/MMC device attributes "erase_size" and "preferred_erase_size" have been
added.
"erase_size" is the minimum size, in bytes, of an erase operation. For
MMC, "erase_size" is the erase group size reported by the card. Note that
"erase_size" does not apply to trim or secure trim operations where the
minimum size is always one 512 byte sector. For SD, "erase_size" is 512
if the card is block-addressed, 0 otherwise.
SD/MMC cards can erase an arbitrarily large area up to and
including the whole card. When erasing a large area it may
be desirable to do it in smaller chunks for three reasons:
1. A single erase command will make all other I/O on the card
wait. This is not a problem if the whole card is being erased, but
erasing one partition will make I/O for another partition on the
same card wait for the duration of the erase - which could be a
several minutes.
2. To be able to inform the user of erase progress.
3. The erase timeout becomes too large to be very useful.
Because the erase timeout contains a margin which is multiplied by
the size of the erase area, the value can end up being several
minutes for large areas.
"erase_size" is not the most efficient unit to erase (especially for SD
where it is just one sector), hence "preferred_erase_size" provides a good
chunk size for erasing large areas.
For MMC, "preferred_erase_size" is the high-capacity erase size if a card
specifies one, otherwise it is based on the capacity of the card.
For SD, "preferred_erase_size" is the allocation unit size specified by
the card.
"preferred_erase_size" is in bytes.
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Cc: Kyungmin Park <kmpark@infradead.org>
Cc: Madhusudhan Chikkature <madhu.cr@ti.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Ben Gardiner <bengardiner@nanometrics.ca>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-12 05:17:46 +08:00
|
|
|
{
|
|
|
|
if (mmc_card_sd(card))
|
2011-04-12 05:13:41 +08:00
|
|
|
return mmc_sd_erase_timeout(card, arg, qty);
|
mmc: add erase, secure erase, trim and secure trim operations
SD/MMC cards tend to support an erase operation. In addition, eMMC v4.4
cards can support secure erase, trim and secure trim operations that are
all variants of the basic erase command.
SD/MMC device attributes "erase_size" and "preferred_erase_size" have been
added.
"erase_size" is the minimum size, in bytes, of an erase operation. For
MMC, "erase_size" is the erase group size reported by the card. Note that
"erase_size" does not apply to trim or secure trim operations where the
minimum size is always one 512 byte sector. For SD, "erase_size" is 512
if the card is block-addressed, 0 otherwise.
SD/MMC cards can erase an arbitrarily large area up to and
including the whole card. When erasing a large area it may
be desirable to do it in smaller chunks for three reasons:
1. A single erase command will make all other I/O on the card
wait. This is not a problem if the whole card is being erased, but
erasing one partition will make I/O for another partition on the
same card wait for the duration of the erase - which could be a
several minutes.
2. To be able to inform the user of erase progress.
3. The erase timeout becomes too large to be very useful.
Because the erase timeout contains a margin which is multiplied by
the size of the erase area, the value can end up being several
minutes for large areas.
"erase_size" is not the most efficient unit to erase (especially for SD
where it is just one sector), hence "preferred_erase_size" provides a good
chunk size for erasing large areas.
For MMC, "preferred_erase_size" is the high-capacity erase size if a card
specifies one, otherwise it is based on the capacity of the card.
For SD, "preferred_erase_size" is the allocation unit size specified by
the card.
"preferred_erase_size" is in bytes.
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Cc: Kyungmin Park <kmpark@infradead.org>
Cc: Madhusudhan Chikkature <madhu.cr@ti.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Ben Gardiner <bengardiner@nanometrics.ca>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-12 05:17:46 +08:00
|
|
|
else
|
2011-04-12 05:13:41 +08:00
|
|
|
return mmc_mmc_erase_timeout(card, arg, qty);
|
mmc: add erase, secure erase, trim and secure trim operations
SD/MMC cards tend to support an erase operation. In addition, eMMC v4.4
cards can support secure erase, trim and secure trim operations that are
all variants of the basic erase command.
SD/MMC device attributes "erase_size" and "preferred_erase_size" have been
added.
"erase_size" is the minimum size, in bytes, of an erase operation. For
MMC, "erase_size" is the erase group size reported by the card. Note that
"erase_size" does not apply to trim or secure trim operations where the
minimum size is always one 512 byte sector. For SD, "erase_size" is 512
if the card is block-addressed, 0 otherwise.
SD/MMC cards can erase an arbitrarily large area up to and
including the whole card. When erasing a large area it may
be desirable to do it in smaller chunks for three reasons:
1. A single erase command will make all other I/O on the card
wait. This is not a problem if the whole card is being erased, but
erasing one partition will make I/O for another partition on the
same card wait for the duration of the erase - which could be a
several minutes.
2. To be able to inform the user of erase progress.
3. The erase timeout becomes too large to be very useful.
Because the erase timeout contains a margin which is multiplied by
the size of the erase area, the value can end up being several
minutes for large areas.
"erase_size" is not the most efficient unit to erase (especially for SD
where it is just one sector), hence "preferred_erase_size" provides a good
chunk size for erasing large areas.
For MMC, "preferred_erase_size" is the high-capacity erase size if a card
specifies one, otherwise it is based on the capacity of the card.
For SD, "preferred_erase_size" is the allocation unit size specified by
the card.
"preferred_erase_size" is in bytes.
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Cc: Kyungmin Park <kmpark@infradead.org>
Cc: Madhusudhan Chikkature <madhu.cr@ti.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Ben Gardiner <bengardiner@nanometrics.ca>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-12 05:17:46 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static int mmc_do_erase(struct mmc_card *card, unsigned int from,
|
|
|
|
unsigned int to, unsigned int arg)
|
|
|
|
{
|
2016-12-19 19:51:18 +08:00
|
|
|
struct mmc_command cmd = {};
|
2016-07-25 16:48:39 +08:00
|
|
|
unsigned int qty = 0, busy_timeout = 0;
|
|
|
|
bool use_r1b_resp = false;
|
mmc: add erase, secure erase, trim and secure trim operations
SD/MMC cards tend to support an erase operation. In addition, eMMC v4.4
cards can support secure erase, trim and secure trim operations that are
all variants of the basic erase command.
SD/MMC device attributes "erase_size" and "preferred_erase_size" have been
added.
"erase_size" is the minimum size, in bytes, of an erase operation. For
MMC, "erase_size" is the erase group size reported by the card. Note that
"erase_size" does not apply to trim or secure trim operations where the
minimum size is always one 512 byte sector. For SD, "erase_size" is 512
if the card is block-addressed, 0 otherwise.
SD/MMC cards can erase an arbitrarily large area up to and
including the whole card. When erasing a large area it may
be desirable to do it in smaller chunks for three reasons:
1. A single erase command will make all other I/O on the card
wait. This is not a problem if the whole card is being erased, but
erasing one partition will make I/O for another partition on the
same card wait for the duration of the erase - which could be a
several minutes.
2. To be able to inform the user of erase progress.
3. The erase timeout becomes too large to be very useful.
Because the erase timeout contains a margin which is multiplied by
the size of the erase area, the value can end up being several
minutes for large areas.
"erase_size" is not the most efficient unit to erase (especially for SD
where it is just one sector), hence "preferred_erase_size" provides a good
chunk size for erasing large areas.
For MMC, "preferred_erase_size" is the high-capacity erase size if a card
specifies one, otherwise it is based on the capacity of the card.
For SD, "preferred_erase_size" is the allocation unit size specified by
the card.
"preferred_erase_size" is in bytes.
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Cc: Kyungmin Park <kmpark@infradead.org>
Cc: Madhusudhan Chikkature <madhu.cr@ti.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Ben Gardiner <bengardiner@nanometrics.ca>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-12 05:17:46 +08:00
|
|
|
int err;
|
|
|
|
|
2015-05-07 18:10:16 +08:00
|
|
|
mmc_retune_hold(card->host);
|
|
|
|
|
mmc: add erase, secure erase, trim and secure trim operations
SD/MMC cards tend to support an erase operation. In addition, eMMC v4.4
cards can support secure erase, trim and secure trim operations that are
all variants of the basic erase command.
SD/MMC device attributes "erase_size" and "preferred_erase_size" have been
added.
"erase_size" is the minimum size, in bytes, of an erase operation. For
MMC, "erase_size" is the erase group size reported by the card. Note that
"erase_size" does not apply to trim or secure trim operations where the
minimum size is always one 512 byte sector. For SD, "erase_size" is 512
if the card is block-addressed, 0 otherwise.
SD/MMC cards can erase an arbitrarily large area up to and
including the whole card. When erasing a large area it may
be desirable to do it in smaller chunks for three reasons:
1. A single erase command will make all other I/O on the card
wait. This is not a problem if the whole card is being erased, but
erasing one partition will make I/O for another partition on the
same card wait for the duration of the erase - which could be a
several minutes.
2. To be able to inform the user of erase progress.
3. The erase timeout becomes too large to be very useful.
Because the erase timeout contains a margin which is multiplied by
the size of the erase area, the value can end up being several
minutes for large areas.
"erase_size" is not the most efficient unit to erase (especially for SD
where it is just one sector), hence "preferred_erase_size" provides a good
chunk size for erasing large areas.
For MMC, "preferred_erase_size" is the high-capacity erase size if a card
specifies one, otherwise it is based on the capacity of the card.
For SD, "preferred_erase_size" is the allocation unit size specified by
the card.
"preferred_erase_size" is in bytes.
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Cc: Kyungmin Park <kmpark@infradead.org>
Cc: Madhusudhan Chikkature <madhu.cr@ti.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Ben Gardiner <bengardiner@nanometrics.ca>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-12 05:17:46 +08:00
|
|
|
/*
|
|
|
|
* qty is used to calculate the erase timeout which depends on how many
|
|
|
|
* erase groups (or allocation units in SD terminology) are affected.
|
|
|
|
* We count erasing part of an erase group as one erase group.
|
|
|
|
* For SD, the allocation units are always a power of 2. For MMC, the
|
|
|
|
* erase group size is almost certainly also power of 2, but it does not
|
|
|
|
* seem to insist on that in the JEDEC standard, so we fall back to
|
|
|
|
* division in that case. SD may not specify an allocation unit size,
|
|
|
|
* in which case the timeout is based on the number of write blocks.
|
|
|
|
*
|
|
|
|
* Note that the timeout for secure trim 2 will only be correct if the
|
|
|
|
* number of erase groups specified is the same as the total of all
|
|
|
|
* preceding secure trim 1 commands. Since the power may have been
|
|
|
|
* lost since the secure trim 1 commands occurred, it is generally
|
|
|
|
* impossible to calculate the secure trim 2 timeout correctly.
|
|
|
|
*/
|
|
|
|
if (card->erase_shift)
|
|
|
|
qty += ((to >> card->erase_shift) -
|
|
|
|
(from >> card->erase_shift)) + 1;
|
|
|
|
else if (mmc_card_sd(card))
|
|
|
|
qty += to - from + 1;
|
|
|
|
else
|
|
|
|
qty += ((to / card->erase_size) -
|
|
|
|
(from / card->erase_size)) + 1;
|
|
|
|
|
|
|
|
if (!mmc_card_blockaddr(card)) {
|
|
|
|
from <<= 9;
|
|
|
|
to <<= 9;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (mmc_card_sd(card))
|
|
|
|
cmd.opcode = SD_ERASE_WR_BLK_START;
|
|
|
|
else
|
|
|
|
cmd.opcode = MMC_ERASE_GROUP_START;
|
|
|
|
cmd.arg = from;
|
|
|
|
cmd.flags = MMC_RSP_SPI_R1 | MMC_RSP_R1 | MMC_CMD_AC;
|
|
|
|
err = mmc_wait_for_cmd(card->host, &cmd, 0);
|
|
|
|
if (err) {
|
2011-10-11 14:14:09 +08:00
|
|
|
pr_err("mmc_erase: group start error %d, "
|
mmc: add erase, secure erase, trim and secure trim operations
SD/MMC cards tend to support an erase operation. In addition, eMMC v4.4
cards can support secure erase, trim and secure trim operations that are
all variants of the basic erase command.
SD/MMC device attributes "erase_size" and "preferred_erase_size" have been
added.
"erase_size" is the minimum size, in bytes, of an erase operation. For
MMC, "erase_size" is the erase group size reported by the card. Note that
"erase_size" does not apply to trim or secure trim operations where the
minimum size is always one 512 byte sector. For SD, "erase_size" is 512
if the card is block-addressed, 0 otherwise.
SD/MMC cards can erase an arbitrarily large area up to and
including the whole card. When erasing a large area it may
be desirable to do it in smaller chunks for three reasons:
1. A single erase command will make all other I/O on the card
wait. This is not a problem if the whole card is being erased, but
erasing one partition will make I/O for another partition on the
same card wait for the duration of the erase - which could be a
several minutes.
2. To be able to inform the user of erase progress.
3. The erase timeout becomes too large to be very useful.
Because the erase timeout contains a margin which is multiplied by
the size of the erase area, the value can end up being several
minutes for large areas.
"erase_size" is not the most efficient unit to erase (especially for SD
where it is just one sector), hence "preferred_erase_size" provides a good
chunk size for erasing large areas.
For MMC, "preferred_erase_size" is the high-capacity erase size if a card
specifies one, otherwise it is based on the capacity of the card.
For SD, "preferred_erase_size" is the allocation unit size specified by
the card.
"preferred_erase_size" is in bytes.
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Cc: Kyungmin Park <kmpark@infradead.org>
Cc: Madhusudhan Chikkature <madhu.cr@ti.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Ben Gardiner <bengardiner@nanometrics.ca>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-12 05:17:46 +08:00
|
|
|
"status %#x\n", err, cmd.resp[0]);
|
2011-08-29 21:42:15 +08:00
|
|
|
err = -EIO;
|
mmc: add erase, secure erase, trim and secure trim operations
SD/MMC cards tend to support an erase operation. In addition, eMMC v4.4
cards can support secure erase, trim and secure trim operations that are
all variants of the basic erase command.
SD/MMC device attributes "erase_size" and "preferred_erase_size" have been
added.
"erase_size" is the minimum size, in bytes, of an erase operation. For
MMC, "erase_size" is the erase group size reported by the card. Note that
"erase_size" does not apply to trim or secure trim operations where the
minimum size is always one 512 byte sector. For SD, "erase_size" is 512
if the card is block-addressed, 0 otherwise.
SD/MMC cards can erase an arbitrarily large area up to and
including the whole card. When erasing a large area it may
be desirable to do it in smaller chunks for three reasons:
1. A single erase command will make all other I/O on the card
wait. This is not a problem if the whole card is being erased, but
erasing one partition will make I/O for another partition on the
same card wait for the duration of the erase - which could be a
several minutes.
2. To be able to inform the user of erase progress.
3. The erase timeout becomes too large to be very useful.
Because the erase timeout contains a margin which is multiplied by
the size of the erase area, the value can end up being several
minutes for large areas.
"erase_size" is not the most efficient unit to erase (especially for SD
where it is just one sector), hence "preferred_erase_size" provides a good
chunk size for erasing large areas.
For MMC, "preferred_erase_size" is the high-capacity erase size if a card
specifies one, otherwise it is based on the capacity of the card.
For SD, "preferred_erase_size" is the allocation unit size specified by
the card.
"preferred_erase_size" is in bytes.
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Cc: Kyungmin Park <kmpark@infradead.org>
Cc: Madhusudhan Chikkature <madhu.cr@ti.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Ben Gardiner <bengardiner@nanometrics.ca>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-12 05:17:46 +08:00
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
memset(&cmd, 0, sizeof(struct mmc_command));
|
|
|
|
if (mmc_card_sd(card))
|
|
|
|
cmd.opcode = SD_ERASE_WR_BLK_END;
|
|
|
|
else
|
|
|
|
cmd.opcode = MMC_ERASE_GROUP_END;
|
|
|
|
cmd.arg = to;
|
|
|
|
cmd.flags = MMC_RSP_SPI_R1 | MMC_RSP_R1 | MMC_CMD_AC;
|
|
|
|
err = mmc_wait_for_cmd(card->host, &cmd, 0);
|
|
|
|
if (err) {
|
2011-10-11 14:14:09 +08:00
|
|
|
pr_err("mmc_erase: group end error %d, status %#x\n",
|
mmc: add erase, secure erase, trim and secure trim operations
SD/MMC cards tend to support an erase operation. In addition, eMMC v4.4
cards can support secure erase, trim and secure trim operations that are
all variants of the basic erase command.
SD/MMC device attributes "erase_size" and "preferred_erase_size" have been
added.
"erase_size" is the minimum size, in bytes, of an erase operation. For
MMC, "erase_size" is the erase group size reported by the card. Note that
"erase_size" does not apply to trim or secure trim operations where the
minimum size is always one 512 byte sector. For SD, "erase_size" is 512
if the card is block-addressed, 0 otherwise.
SD/MMC cards can erase an arbitrarily large area up to and
including the whole card. When erasing a large area it may
be desirable to do it in smaller chunks for three reasons:
1. A single erase command will make all other I/O on the card
wait. This is not a problem if the whole card is being erased, but
erasing one partition will make I/O for another partition on the
same card wait for the duration of the erase - which could be a
several minutes.
2. To be able to inform the user of erase progress.
3. The erase timeout becomes too large to be very useful.
Because the erase timeout contains a margin which is multiplied by
the size of the erase area, the value can end up being several
minutes for large areas.
"erase_size" is not the most efficient unit to erase (especially for SD
where it is just one sector), hence "preferred_erase_size" provides a good
chunk size for erasing large areas.
For MMC, "preferred_erase_size" is the high-capacity erase size if a card
specifies one, otherwise it is based on the capacity of the card.
For SD, "preferred_erase_size" is the allocation unit size specified by
the card.
"preferred_erase_size" is in bytes.
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Cc: Kyungmin Park <kmpark@infradead.org>
Cc: Madhusudhan Chikkature <madhu.cr@ti.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Ben Gardiner <bengardiner@nanometrics.ca>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-12 05:17:46 +08:00
|
|
|
err, cmd.resp[0]);
|
2011-08-29 21:42:15 +08:00
|
|
|
err = -EIO;
|
mmc: add erase, secure erase, trim and secure trim operations
SD/MMC cards tend to support an erase operation. In addition, eMMC v4.4
cards can support secure erase, trim and secure trim operations that are
all variants of the basic erase command.
SD/MMC device attributes "erase_size" and "preferred_erase_size" have been
added.
"erase_size" is the minimum size, in bytes, of an erase operation. For
MMC, "erase_size" is the erase group size reported by the card. Note that
"erase_size" does not apply to trim or secure trim operations where the
minimum size is always one 512 byte sector. For SD, "erase_size" is 512
if the card is block-addressed, 0 otherwise.
SD/MMC cards can erase an arbitrarily large area up to and
including the whole card. When erasing a large area it may
be desirable to do it in smaller chunks for three reasons:
1. A single erase command will make all other I/O on the card
wait. This is not a problem if the whole card is being erased, but
erasing one partition will make I/O for another partition on the
same card wait for the duration of the erase - which could be a
several minutes.
2. To be able to inform the user of erase progress.
3. The erase timeout becomes too large to be very useful.
Because the erase timeout contains a margin which is multiplied by
the size of the erase area, the value can end up being several
minutes for large areas.
"erase_size" is not the most efficient unit to erase (especially for SD
where it is just one sector), hence "preferred_erase_size" provides a good
chunk size for erasing large areas.
For MMC, "preferred_erase_size" is the high-capacity erase size if a card
specifies one, otherwise it is based on the capacity of the card.
For SD, "preferred_erase_size" is the allocation unit size specified by
the card.
"preferred_erase_size" is in bytes.
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Cc: Kyungmin Park <kmpark@infradead.org>
Cc: Madhusudhan Chikkature <madhu.cr@ti.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Ben Gardiner <bengardiner@nanometrics.ca>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-12 05:17:46 +08:00
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
memset(&cmd, 0, sizeof(struct mmc_command));
|
|
|
|
cmd.opcode = MMC_ERASE;
|
|
|
|
cmd.arg = arg;
|
2016-07-25 16:48:39 +08:00
|
|
|
busy_timeout = mmc_erase_timeout(card, arg, qty);
|
|
|
|
/*
|
|
|
|
* If the host controller supports busy signalling and the timeout for
|
|
|
|
* the erase operation does not exceed the max_busy_timeout, we should
|
|
|
|
* use R1B response. Or we need to prevent the host from doing hw busy
|
|
|
|
* detection, which is done by converting to a R1 response instead.
|
2020-03-10 21:43:00 +08:00
|
|
|
* Note, some hosts requires R1B, which also means they are on their own
|
|
|
|
* when it comes to deal with the busy timeout.
|
2016-07-25 16:48:39 +08:00
|
|
|
*/
|
2020-03-10 21:43:00 +08:00
|
|
|
if (!(card->host->caps & MMC_CAP_NEED_RSP_BUSY) &&
|
|
|
|
card->host->max_busy_timeout &&
|
2016-07-25 16:48:39 +08:00
|
|
|
busy_timeout > card->host->max_busy_timeout) {
|
|
|
|
cmd.flags = MMC_RSP_SPI_R1 | MMC_RSP_R1 | MMC_CMD_AC;
|
|
|
|
} else {
|
|
|
|
cmd.flags = MMC_RSP_SPI_R1B | MMC_RSP_R1B | MMC_CMD_AC;
|
|
|
|
cmd.busy_timeout = busy_timeout;
|
|
|
|
use_r1b_resp = true;
|
|
|
|
}
|
|
|
|
|
mmc: add erase, secure erase, trim and secure trim operations
SD/MMC cards tend to support an erase operation. In addition, eMMC v4.4
cards can support secure erase, trim and secure trim operations that are
all variants of the basic erase command.
SD/MMC device attributes "erase_size" and "preferred_erase_size" have been
added.
"erase_size" is the minimum size, in bytes, of an erase operation. For
MMC, "erase_size" is the erase group size reported by the card. Note that
"erase_size" does not apply to trim or secure trim operations where the
minimum size is always one 512 byte sector. For SD, "erase_size" is 512
if the card is block-addressed, 0 otherwise.
SD/MMC cards can erase an arbitrarily large area up to and
including the whole card. When erasing a large area it may
be desirable to do it in smaller chunks for three reasons:
1. A single erase command will make all other I/O on the card
wait. This is not a problem if the whole card is being erased, but
erasing one partition will make I/O for another partition on the
same card wait for the duration of the erase - which could be a
several minutes.
2. To be able to inform the user of erase progress.
3. The erase timeout becomes too large to be very useful.
Because the erase timeout contains a margin which is multiplied by
the size of the erase area, the value can end up being several
minutes for large areas.
"erase_size" is not the most efficient unit to erase (especially for SD
where it is just one sector), hence "preferred_erase_size" provides a good
chunk size for erasing large areas.
For MMC, "preferred_erase_size" is the high-capacity erase size if a card
specifies one, otherwise it is based on the capacity of the card.
For SD, "preferred_erase_size" is the allocation unit size specified by
the card.
"preferred_erase_size" is in bytes.
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Cc: Kyungmin Park <kmpark@infradead.org>
Cc: Madhusudhan Chikkature <madhu.cr@ti.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Ben Gardiner <bengardiner@nanometrics.ca>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-12 05:17:46 +08:00
|
|
|
err = mmc_wait_for_cmd(card->host, &cmd, 0);
|
|
|
|
if (err) {
|
2011-10-11 14:14:09 +08:00
|
|
|
pr_err("mmc_erase: erase error %d, status %#x\n",
|
mmc: add erase, secure erase, trim and secure trim operations
SD/MMC cards tend to support an erase operation. In addition, eMMC v4.4
cards can support secure erase, trim and secure trim operations that are
all variants of the basic erase command.
SD/MMC device attributes "erase_size" and "preferred_erase_size" have been
added.
"erase_size" is the minimum size, in bytes, of an erase operation. For
MMC, "erase_size" is the erase group size reported by the card. Note that
"erase_size" does not apply to trim or secure trim operations where the
minimum size is always one 512 byte sector. For SD, "erase_size" is 512
if the card is block-addressed, 0 otherwise.
SD/MMC cards can erase an arbitrarily large area up to and
including the whole card. When erasing a large area it may
be desirable to do it in smaller chunks for three reasons:
1. A single erase command will make all other I/O on the card
wait. This is not a problem if the whole card is being erased, but
erasing one partition will make I/O for another partition on the
same card wait for the duration of the erase - which could be a
several minutes.
2. To be able to inform the user of erase progress.
3. The erase timeout becomes too large to be very useful.
Because the erase timeout contains a margin which is multiplied by
the size of the erase area, the value can end up being several
minutes for large areas.
"erase_size" is not the most efficient unit to erase (especially for SD
where it is just one sector), hence "preferred_erase_size" provides a good
chunk size for erasing large areas.
For MMC, "preferred_erase_size" is the high-capacity erase size if a card
specifies one, otherwise it is based on the capacity of the card.
For SD, "preferred_erase_size" is the allocation unit size specified by
the card.
"preferred_erase_size" is in bytes.
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Cc: Kyungmin Park <kmpark@infradead.org>
Cc: Madhusudhan Chikkature <madhu.cr@ti.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Ben Gardiner <bengardiner@nanometrics.ca>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-12 05:17:46 +08:00
|
|
|
err, cmd.resp[0]);
|
|
|
|
err = -EIO;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (mmc_host_is_spi(card->host))
|
|
|
|
goto out;
|
|
|
|
|
2016-07-25 16:48:39 +08:00
|
|
|
/*
|
|
|
|
* In case of when R1B + MMC_CAP_WAIT_WHILE_BUSY is used, the polling
|
|
|
|
* shall be avoided.
|
|
|
|
*/
|
|
|
|
if ((card->host->caps & MMC_CAP_WAIT_WHILE_BUSY) && use_r1b_resp)
|
|
|
|
goto out;
|
|
|
|
|
2020-02-04 16:54:45 +08:00
|
|
|
/* Let's poll to find out when the erase operation completes. */
|
|
|
|
err = mmc_poll_for_busy(card, busy_timeout, MMC_BUSY_ERASE);
|
2012-11-16 23:31:41 +08:00
|
|
|
|
mmc: add erase, secure erase, trim and secure trim operations
SD/MMC cards tend to support an erase operation. In addition, eMMC v4.4
cards can support secure erase, trim and secure trim operations that are
all variants of the basic erase command.
SD/MMC device attributes "erase_size" and "preferred_erase_size" have been
added.
"erase_size" is the minimum size, in bytes, of an erase operation. For
MMC, "erase_size" is the erase group size reported by the card. Note that
"erase_size" does not apply to trim or secure trim operations where the
minimum size is always one 512 byte sector. For SD, "erase_size" is 512
if the card is block-addressed, 0 otherwise.
SD/MMC cards can erase an arbitrarily large area up to and
including the whole card. When erasing a large area it may
be desirable to do it in smaller chunks for three reasons:
1. A single erase command will make all other I/O on the card
wait. This is not a problem if the whole card is being erased, but
erasing one partition will make I/O for another partition on the
same card wait for the duration of the erase - which could be a
several minutes.
2. To be able to inform the user of erase progress.
3. The erase timeout becomes too large to be very useful.
Because the erase timeout contains a margin which is multiplied by
the size of the erase area, the value can end up being several
minutes for large areas.
"erase_size" is not the most efficient unit to erase (especially for SD
where it is just one sector), hence "preferred_erase_size" provides a good
chunk size for erasing large areas.
For MMC, "preferred_erase_size" is the high-capacity erase size if a card
specifies one, otherwise it is based on the capacity of the card.
For SD, "preferred_erase_size" is the allocation unit size specified by
the card.
"preferred_erase_size" is in bytes.
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Cc: Kyungmin Park <kmpark@infradead.org>
Cc: Madhusudhan Chikkature <madhu.cr@ti.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Ben Gardiner <bengardiner@nanometrics.ca>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-12 05:17:46 +08:00
|
|
|
out:
|
2015-05-07 18:10:16 +08:00
|
|
|
mmc_retune_release(card->host);
|
mmc: add erase, secure erase, trim and secure trim operations
SD/MMC cards tend to support an erase operation. In addition, eMMC v4.4
cards can support secure erase, trim and secure trim operations that are
all variants of the basic erase command.
SD/MMC device attributes "erase_size" and "preferred_erase_size" have been
added.
"erase_size" is the minimum size, in bytes, of an erase operation. For
MMC, "erase_size" is the erase group size reported by the card. Note that
"erase_size" does not apply to trim or secure trim operations where the
minimum size is always one 512 byte sector. For SD, "erase_size" is 512
if the card is block-addressed, 0 otherwise.
SD/MMC cards can erase an arbitrarily large area up to and
including the whole card. When erasing a large area it may
be desirable to do it in smaller chunks for three reasons:
1. A single erase command will make all other I/O on the card
wait. This is not a problem if the whole card is being erased, but
erasing one partition will make I/O for another partition on the
same card wait for the duration of the erase - which could be a
several minutes.
2. To be able to inform the user of erase progress.
3. The erase timeout becomes too large to be very useful.
Because the erase timeout contains a margin which is multiplied by
the size of the erase area, the value can end up being several
minutes for large areas.
"erase_size" is not the most efficient unit to erase (especially for SD
where it is just one sector), hence "preferred_erase_size" provides a good
chunk size for erasing large areas.
For MMC, "preferred_erase_size" is the high-capacity erase size if a card
specifies one, otherwise it is based on the capacity of the card.
For SD, "preferred_erase_size" is the allocation unit size specified by
the card.
"preferred_erase_size" is in bytes.
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Cc: Kyungmin Park <kmpark@infradead.org>
Cc: Madhusudhan Chikkature <madhu.cr@ti.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Ben Gardiner <bengardiner@nanometrics.ca>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-12 05:17:46 +08:00
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2016-09-07 10:38:24 +08:00
|
|
|
static unsigned int mmc_align_erase_size(struct mmc_card *card,
|
|
|
|
unsigned int *from,
|
|
|
|
unsigned int *to,
|
|
|
|
unsigned int nr)
|
|
|
|
{
|
|
|
|
unsigned int from_new = *from, nr_new = nr, rem;
|
|
|
|
|
2016-09-07 10:38:25 +08:00
|
|
|
/*
|
|
|
|
* When the 'card->erase_size' is power of 2, we can use round_up/down()
|
|
|
|
* to align the erase size efficiently.
|
|
|
|
*/
|
|
|
|
if (is_power_of_2(card->erase_size)) {
|
|
|
|
unsigned int temp = from_new;
|
|
|
|
|
|
|
|
from_new = round_up(temp, card->erase_size);
|
|
|
|
rem = from_new - temp;
|
|
|
|
|
2016-09-07 10:38:24 +08:00
|
|
|
if (nr_new > rem)
|
|
|
|
nr_new -= rem;
|
|
|
|
else
|
|
|
|
return 0;
|
|
|
|
|
2016-09-07 10:38:25 +08:00
|
|
|
nr_new = round_down(nr_new, card->erase_size);
|
|
|
|
} else {
|
|
|
|
rem = from_new % card->erase_size;
|
|
|
|
if (rem) {
|
|
|
|
rem = card->erase_size - rem;
|
|
|
|
from_new += rem;
|
|
|
|
if (nr_new > rem)
|
|
|
|
nr_new -= rem;
|
|
|
|
else
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
rem = nr_new % card->erase_size;
|
|
|
|
if (rem)
|
|
|
|
nr_new -= rem;
|
|
|
|
}
|
2016-09-07 10:38:24 +08:00
|
|
|
|
|
|
|
if (nr_new == 0)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
*to = from_new + nr_new;
|
|
|
|
*from = from_new;
|
|
|
|
|
|
|
|
return nr_new;
|
|
|
|
}
|
|
|
|
|
mmc: add erase, secure erase, trim and secure trim operations
SD/MMC cards tend to support an erase operation. In addition, eMMC v4.4
cards can support secure erase, trim and secure trim operations that are
all variants of the basic erase command.
SD/MMC device attributes "erase_size" and "preferred_erase_size" have been
added.
"erase_size" is the minimum size, in bytes, of an erase operation. For
MMC, "erase_size" is the erase group size reported by the card. Note that
"erase_size" does not apply to trim or secure trim operations where the
minimum size is always one 512 byte sector. For SD, "erase_size" is 512
if the card is block-addressed, 0 otherwise.
SD/MMC cards can erase an arbitrarily large area up to and
including the whole card. When erasing a large area it may
be desirable to do it in smaller chunks for three reasons:
1. A single erase command will make all other I/O on the card
wait. This is not a problem if the whole card is being erased, but
erasing one partition will make I/O for another partition on the
same card wait for the duration of the erase - which could be a
several minutes.
2. To be able to inform the user of erase progress.
3. The erase timeout becomes too large to be very useful.
Because the erase timeout contains a margin which is multiplied by
the size of the erase area, the value can end up being several
minutes for large areas.
"erase_size" is not the most efficient unit to erase (especially for SD
where it is just one sector), hence "preferred_erase_size" provides a good
chunk size for erasing large areas.
For MMC, "preferred_erase_size" is the high-capacity erase size if a card
specifies one, otherwise it is based on the capacity of the card.
For SD, "preferred_erase_size" is the allocation unit size specified by
the card.
"preferred_erase_size" is in bytes.
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Cc: Kyungmin Park <kmpark@infradead.org>
Cc: Madhusudhan Chikkature <madhu.cr@ti.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Ben Gardiner <bengardiner@nanometrics.ca>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-12 05:17:46 +08:00
|
|
|
/**
|
|
|
|
* mmc_erase - erase sectors.
|
|
|
|
* @card: card to erase
|
|
|
|
* @from: first sector to erase
|
|
|
|
* @nr: number of sectors to erase
|
2019-02-26 23:10:24 +08:00
|
|
|
* @arg: erase command argument
|
mmc: add erase, secure erase, trim and secure trim operations
SD/MMC cards tend to support an erase operation. In addition, eMMC v4.4
cards can support secure erase, trim and secure trim operations that are
all variants of the basic erase command.
SD/MMC device attributes "erase_size" and "preferred_erase_size" have been
added.
"erase_size" is the minimum size, in bytes, of an erase operation. For
MMC, "erase_size" is the erase group size reported by the card. Note that
"erase_size" does not apply to trim or secure trim operations where the
minimum size is always one 512 byte sector. For SD, "erase_size" is 512
if the card is block-addressed, 0 otherwise.
SD/MMC cards can erase an arbitrarily large area up to and
including the whole card. When erasing a large area it may
be desirable to do it in smaller chunks for three reasons:
1. A single erase command will make all other I/O on the card
wait. This is not a problem if the whole card is being erased, but
erasing one partition will make I/O for another partition on the
same card wait for the duration of the erase - which could be a
several minutes.
2. To be able to inform the user of erase progress.
3. The erase timeout becomes too large to be very useful.
Because the erase timeout contains a margin which is multiplied by
the size of the erase area, the value can end up being several
minutes for large areas.
"erase_size" is not the most efficient unit to erase (especially for SD
where it is just one sector), hence "preferred_erase_size" provides a good
chunk size for erasing large areas.
For MMC, "preferred_erase_size" is the high-capacity erase size if a card
specifies one, otherwise it is based on the capacity of the card.
For SD, "preferred_erase_size" is the allocation unit size specified by
the card.
"preferred_erase_size" is in bytes.
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Cc: Kyungmin Park <kmpark@infradead.org>
Cc: Madhusudhan Chikkature <madhu.cr@ti.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Ben Gardiner <bengardiner@nanometrics.ca>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-12 05:17:46 +08:00
|
|
|
*
|
|
|
|
* Caller must claim host before calling this function.
|
|
|
|
*/
|
|
|
|
int mmc_erase(struct mmc_card *card, unsigned int from, unsigned int nr,
|
|
|
|
unsigned int arg)
|
|
|
|
{
|
|
|
|
unsigned int rem, to = from + nr;
|
2015-06-23 17:43:52 +08:00
|
|
|
int err;
|
mmc: add erase, secure erase, trim and secure trim operations
SD/MMC cards tend to support an erase operation. In addition, eMMC v4.4
cards can support secure erase, trim and secure trim operations that are
all variants of the basic erase command.
SD/MMC device attributes "erase_size" and "preferred_erase_size" have been
added.
"erase_size" is the minimum size, in bytes, of an erase operation. For
MMC, "erase_size" is the erase group size reported by the card. Note that
"erase_size" does not apply to trim or secure trim operations where the
minimum size is always one 512 byte sector. For SD, "erase_size" is 512
if the card is block-addressed, 0 otherwise.
SD/MMC cards can erase an arbitrarily large area up to and
including the whole card. When erasing a large area it may
be desirable to do it in smaller chunks for three reasons:
1. A single erase command will make all other I/O on the card
wait. This is not a problem if the whole card is being erased, but
erasing one partition will make I/O for another partition on the
same card wait for the duration of the erase - which could be a
several minutes.
2. To be able to inform the user of erase progress.
3. The erase timeout becomes too large to be very useful.
Because the erase timeout contains a margin which is multiplied by
the size of the erase area, the value can end up being several
minutes for large areas.
"erase_size" is not the most efficient unit to erase (especially for SD
where it is just one sector), hence "preferred_erase_size" provides a good
chunk size for erasing large areas.
For MMC, "preferred_erase_size" is the high-capacity erase size if a card
specifies one, otherwise it is based on the capacity of the card.
For SD, "preferred_erase_size" is the allocation unit size specified by
the card.
"preferred_erase_size" is in bytes.
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Cc: Kyungmin Park <kmpark@infradead.org>
Cc: Madhusudhan Chikkature <madhu.cr@ti.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Ben Gardiner <bengardiner@nanometrics.ca>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-12 05:17:46 +08:00
|
|
|
|
2020-05-08 19:28:53 +08:00
|
|
|
if (!(card->csd.cmdclass & CCC_ERASE))
|
mmc: add erase, secure erase, trim and secure trim operations
SD/MMC cards tend to support an erase operation. In addition, eMMC v4.4
cards can support secure erase, trim and secure trim operations that are
all variants of the basic erase command.
SD/MMC device attributes "erase_size" and "preferred_erase_size" have been
added.
"erase_size" is the minimum size, in bytes, of an erase operation. For
MMC, "erase_size" is the erase group size reported by the card. Note that
"erase_size" does not apply to trim or secure trim operations where the
minimum size is always one 512 byte sector. For SD, "erase_size" is 512
if the card is block-addressed, 0 otherwise.
SD/MMC cards can erase an arbitrarily large area up to and
including the whole card. When erasing a large area it may
be desirable to do it in smaller chunks for three reasons:
1. A single erase command will make all other I/O on the card
wait. This is not a problem if the whole card is being erased, but
erasing one partition will make I/O for another partition on the
same card wait for the duration of the erase - which could be a
several minutes.
2. To be able to inform the user of erase progress.
3. The erase timeout becomes too large to be very useful.
Because the erase timeout contains a margin which is multiplied by
the size of the erase area, the value can end up being several
minutes for large areas.
"erase_size" is not the most efficient unit to erase (especially for SD
where it is just one sector), hence "preferred_erase_size" provides a good
chunk size for erasing large areas.
For MMC, "preferred_erase_size" is the high-capacity erase size if a card
specifies one, otherwise it is based on the capacity of the card.
For SD, "preferred_erase_size" is the allocation unit size specified by
the card.
"preferred_erase_size" is in bytes.
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Cc: Kyungmin Park <kmpark@infradead.org>
Cc: Madhusudhan Chikkature <madhu.cr@ti.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Ben Gardiner <bengardiner@nanometrics.ca>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-12 05:17:46 +08:00
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
|
|
|
if (!card->erase_size)
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
2019-02-26 23:10:24 +08:00
|
|
|
if (mmc_card_sd(card) && arg != SD_ERASE_ARG && arg != SD_DISCARD_ARG)
|
mmc: add erase, secure erase, trim and secure trim operations
SD/MMC cards tend to support an erase operation. In addition, eMMC v4.4
cards can support secure erase, trim and secure trim operations that are
all variants of the basic erase command.
SD/MMC device attributes "erase_size" and "preferred_erase_size" have been
added.
"erase_size" is the minimum size, in bytes, of an erase operation. For
MMC, "erase_size" is the erase group size reported by the card. Note that
"erase_size" does not apply to trim or secure trim operations where the
minimum size is always one 512 byte sector. For SD, "erase_size" is 512
if the card is block-addressed, 0 otherwise.
SD/MMC cards can erase an arbitrarily large area up to and
including the whole card. When erasing a large area it may
be desirable to do it in smaller chunks for three reasons:
1. A single erase command will make all other I/O on the card
wait. This is not a problem if the whole card is being erased, but
erasing one partition will make I/O for another partition on the
same card wait for the duration of the erase - which could be a
several minutes.
2. To be able to inform the user of erase progress.
3. The erase timeout becomes too large to be very useful.
Because the erase timeout contains a margin which is multiplied by
the size of the erase area, the value can end up being several
minutes for large areas.
"erase_size" is not the most efficient unit to erase (especially for SD
where it is just one sector), hence "preferred_erase_size" provides a good
chunk size for erasing large areas.
For MMC, "preferred_erase_size" is the high-capacity erase size if a card
specifies one, otherwise it is based on the capacity of the card.
For SD, "preferred_erase_size" is the allocation unit size specified by
the card.
"preferred_erase_size" is in bytes.
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Cc: Kyungmin Park <kmpark@infradead.org>
Cc: Madhusudhan Chikkature <madhu.cr@ti.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Ben Gardiner <bengardiner@nanometrics.ca>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-12 05:17:46 +08:00
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
2019-02-26 23:10:24 +08:00
|
|
|
if (mmc_card_mmc(card) && (arg & MMC_SECURE_ARGS) &&
|
mmc: add erase, secure erase, trim and secure trim operations
SD/MMC cards tend to support an erase operation. In addition, eMMC v4.4
cards can support secure erase, trim and secure trim operations that are
all variants of the basic erase command.
SD/MMC device attributes "erase_size" and "preferred_erase_size" have been
added.
"erase_size" is the minimum size, in bytes, of an erase operation. For
MMC, "erase_size" is the erase group size reported by the card. Note that
"erase_size" does not apply to trim or secure trim operations where the
minimum size is always one 512 byte sector. For SD, "erase_size" is 512
if the card is block-addressed, 0 otherwise.
SD/MMC cards can erase an arbitrarily large area up to and
including the whole card. When erasing a large area it may
be desirable to do it in smaller chunks for three reasons:
1. A single erase command will make all other I/O on the card
wait. This is not a problem if the whole card is being erased, but
erasing one partition will make I/O for another partition on the
same card wait for the duration of the erase - which could be a
several minutes.
2. To be able to inform the user of erase progress.
3. The erase timeout becomes too large to be very useful.
Because the erase timeout contains a margin which is multiplied by
the size of the erase area, the value can end up being several
minutes for large areas.
"erase_size" is not the most efficient unit to erase (especially for SD
where it is just one sector), hence "preferred_erase_size" provides a good
chunk size for erasing large areas.
For MMC, "preferred_erase_size" is the high-capacity erase size if a card
specifies one, otherwise it is based on the capacity of the card.
For SD, "preferred_erase_size" is the allocation unit size specified by
the card.
"preferred_erase_size" is in bytes.
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Cc: Kyungmin Park <kmpark@infradead.org>
Cc: Madhusudhan Chikkature <madhu.cr@ti.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Ben Gardiner <bengardiner@nanometrics.ca>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-12 05:17:46 +08:00
|
|
|
!(card->ext_csd.sec_feature_support & EXT_CSD_SEC_ER_EN))
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
2019-02-26 23:10:24 +08:00
|
|
|
if (mmc_card_mmc(card) && (arg & MMC_TRIM_ARGS) &&
|
mmc: add erase, secure erase, trim and secure trim operations
SD/MMC cards tend to support an erase operation. In addition, eMMC v4.4
cards can support secure erase, trim and secure trim operations that are
all variants of the basic erase command.
SD/MMC device attributes "erase_size" and "preferred_erase_size" have been
added.
"erase_size" is the minimum size, in bytes, of an erase operation. For
MMC, "erase_size" is the erase group size reported by the card. Note that
"erase_size" does not apply to trim or secure trim operations where the
minimum size is always one 512 byte sector. For SD, "erase_size" is 512
if the card is block-addressed, 0 otherwise.
SD/MMC cards can erase an arbitrarily large area up to and
including the whole card. When erasing a large area it may
be desirable to do it in smaller chunks for three reasons:
1. A single erase command will make all other I/O on the card
wait. This is not a problem if the whole card is being erased, but
erasing one partition will make I/O for another partition on the
same card wait for the duration of the erase - which could be a
several minutes.
2. To be able to inform the user of erase progress.
3. The erase timeout becomes too large to be very useful.
Because the erase timeout contains a margin which is multiplied by
the size of the erase area, the value can end up being several
minutes for large areas.
"erase_size" is not the most efficient unit to erase (especially for SD
where it is just one sector), hence "preferred_erase_size" provides a good
chunk size for erasing large areas.
For MMC, "preferred_erase_size" is the high-capacity erase size if a card
specifies one, otherwise it is based on the capacity of the card.
For SD, "preferred_erase_size" is the allocation unit size specified by
the card.
"preferred_erase_size" is in bytes.
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Cc: Kyungmin Park <kmpark@infradead.org>
Cc: Madhusudhan Chikkature <madhu.cr@ti.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Ben Gardiner <bengardiner@nanometrics.ca>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-12 05:17:46 +08:00
|
|
|
!(card->ext_csd.sec_feature_support & EXT_CSD_SEC_GB_CL_EN))
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
|
|
|
if (arg == MMC_SECURE_ERASE_ARG) {
|
|
|
|
if (from % card->erase_size || nr % card->erase_size)
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2016-09-07 10:38:24 +08:00
|
|
|
if (arg == MMC_ERASE_ARG)
|
|
|
|
nr = mmc_align_erase_size(card, &from, &to, nr);
|
mmc: add erase, secure erase, trim and secure trim operations
SD/MMC cards tend to support an erase operation. In addition, eMMC v4.4
cards can support secure erase, trim and secure trim operations that are
all variants of the basic erase command.
SD/MMC device attributes "erase_size" and "preferred_erase_size" have been
added.
"erase_size" is the minimum size, in bytes, of an erase operation. For
MMC, "erase_size" is the erase group size reported by the card. Note that
"erase_size" does not apply to trim or secure trim operations where the
minimum size is always one 512 byte sector. For SD, "erase_size" is 512
if the card is block-addressed, 0 otherwise.
SD/MMC cards can erase an arbitrarily large area up to and
including the whole card. When erasing a large area it may
be desirable to do it in smaller chunks for three reasons:
1. A single erase command will make all other I/O on the card
wait. This is not a problem if the whole card is being erased, but
erasing one partition will make I/O for another partition on the
same card wait for the duration of the erase - which could be a
several minutes.
2. To be able to inform the user of erase progress.
3. The erase timeout becomes too large to be very useful.
Because the erase timeout contains a margin which is multiplied by
the size of the erase area, the value can end up being several
minutes for large areas.
"erase_size" is not the most efficient unit to erase (especially for SD
where it is just one sector), hence "preferred_erase_size" provides a good
chunk size for erasing large areas.
For MMC, "preferred_erase_size" is the high-capacity erase size if a card
specifies one, otherwise it is based on the capacity of the card.
For SD, "preferred_erase_size" is the allocation unit size specified by
the card.
"preferred_erase_size" is in bytes.
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Cc: Kyungmin Park <kmpark@infradead.org>
Cc: Madhusudhan Chikkature <madhu.cr@ti.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Ben Gardiner <bengardiner@nanometrics.ca>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-12 05:17:46 +08:00
|
|
|
|
|
|
|
if (nr == 0)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (to <= from)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
/* 'from' and 'to' are inclusive */
|
|
|
|
to -= 1;
|
|
|
|
|
2015-06-23 17:43:52 +08:00
|
|
|
/*
|
|
|
|
* Special case where only one erase-group fits in the timeout budget:
|
|
|
|
* If the region crosses an erase-group boundary on this particular
|
|
|
|
* case, we will be trimming more than one erase-group which, does not
|
|
|
|
* fit in the timeout budget of the controller, so we need to split it
|
|
|
|
* and call mmc_do_erase() twice if necessary. This special case is
|
|
|
|
* identified by the card->eg_boundary flag.
|
|
|
|
*/
|
2015-08-04 14:58:33 +08:00
|
|
|
rem = card->erase_size - (from % card->erase_size);
|
|
|
|
if ((arg & MMC_TRIM_ARGS) && (card->eg_boundary) && (nr > rem)) {
|
2015-06-23 17:43:52 +08:00
|
|
|
err = mmc_do_erase(card, from, from + rem - 1, arg);
|
|
|
|
from += rem;
|
|
|
|
if ((err) || (to <= from))
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
mmc: add erase, secure erase, trim and secure trim operations
SD/MMC cards tend to support an erase operation. In addition, eMMC v4.4
cards can support secure erase, trim and secure trim operations that are
all variants of the basic erase command.
SD/MMC device attributes "erase_size" and "preferred_erase_size" have been
added.
"erase_size" is the minimum size, in bytes, of an erase operation. For
MMC, "erase_size" is the erase group size reported by the card. Note that
"erase_size" does not apply to trim or secure trim operations where the
minimum size is always one 512 byte sector. For SD, "erase_size" is 512
if the card is block-addressed, 0 otherwise.
SD/MMC cards can erase an arbitrarily large area up to and
including the whole card. When erasing a large area it may
be desirable to do it in smaller chunks for three reasons:
1. A single erase command will make all other I/O on the card
wait. This is not a problem if the whole card is being erased, but
erasing one partition will make I/O for another partition on the
same card wait for the duration of the erase - which could be a
several minutes.
2. To be able to inform the user of erase progress.
3. The erase timeout becomes too large to be very useful.
Because the erase timeout contains a margin which is multiplied by
the size of the erase area, the value can end up being several
minutes for large areas.
"erase_size" is not the most efficient unit to erase (especially for SD
where it is just one sector), hence "preferred_erase_size" provides a good
chunk size for erasing large areas.
For MMC, "preferred_erase_size" is the high-capacity erase size if a card
specifies one, otherwise it is based on the capacity of the card.
For SD, "preferred_erase_size" is the allocation unit size specified by
the card.
"preferred_erase_size" is in bytes.
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Cc: Kyungmin Park <kmpark@infradead.org>
Cc: Madhusudhan Chikkature <madhu.cr@ti.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Ben Gardiner <bengardiner@nanometrics.ca>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-12 05:17:46 +08:00
|
|
|
return mmc_do_erase(card, from, to, arg);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(mmc_erase);
|
|
|
|
|
|
|
|
int mmc_can_erase(struct mmc_card *card)
|
|
|
|
{
|
2020-05-08 19:28:53 +08:00
|
|
|
if (card->csd.cmdclass & CCC_ERASE && card->erase_size)
|
mmc: add erase, secure erase, trim and secure trim operations
SD/MMC cards tend to support an erase operation. In addition, eMMC v4.4
cards can support secure erase, trim and secure trim operations that are
all variants of the basic erase command.
SD/MMC device attributes "erase_size" and "preferred_erase_size" have been
added.
"erase_size" is the minimum size, in bytes, of an erase operation. For
MMC, "erase_size" is the erase group size reported by the card. Note that
"erase_size" does not apply to trim or secure trim operations where the
minimum size is always one 512 byte sector. For SD, "erase_size" is 512
if the card is block-addressed, 0 otherwise.
SD/MMC cards can erase an arbitrarily large area up to and
including the whole card. When erasing a large area it may
be desirable to do it in smaller chunks for three reasons:
1. A single erase command will make all other I/O on the card
wait. This is not a problem if the whole card is being erased, but
erasing one partition will make I/O for another partition on the
same card wait for the duration of the erase - which could be a
several minutes.
2. To be able to inform the user of erase progress.
3. The erase timeout becomes too large to be very useful.
Because the erase timeout contains a margin which is multiplied by
the size of the erase area, the value can end up being several
minutes for large areas.
"erase_size" is not the most efficient unit to erase (especially for SD
where it is just one sector), hence "preferred_erase_size" provides a good
chunk size for erasing large areas.
For MMC, "preferred_erase_size" is the high-capacity erase size if a card
specifies one, otherwise it is based on the capacity of the card.
For SD, "preferred_erase_size" is the allocation unit size specified by
the card.
"preferred_erase_size" is in bytes.
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Cc: Kyungmin Park <kmpark@infradead.org>
Cc: Madhusudhan Chikkature <madhu.cr@ti.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Ben Gardiner <bengardiner@nanometrics.ca>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-12 05:17:46 +08:00
|
|
|
return 1;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(mmc_can_erase);
|
|
|
|
|
|
|
|
int mmc_can_trim(struct mmc_card *card)
|
|
|
|
{
|
2015-08-12 13:08:32 +08:00
|
|
|
if ((card->ext_csd.sec_feature_support & EXT_CSD_SEC_GB_CL_EN) &&
|
|
|
|
(!(card->quirks & MMC_QUIRK_TRIM_BROKEN)))
|
mmc: add erase, secure erase, trim and secure trim operations
SD/MMC cards tend to support an erase operation. In addition, eMMC v4.4
cards can support secure erase, trim and secure trim operations that are
all variants of the basic erase command.
SD/MMC device attributes "erase_size" and "preferred_erase_size" have been
added.
"erase_size" is the minimum size, in bytes, of an erase operation. For
MMC, "erase_size" is the erase group size reported by the card. Note that
"erase_size" does not apply to trim or secure trim operations where the
minimum size is always one 512 byte sector. For SD, "erase_size" is 512
if the card is block-addressed, 0 otherwise.
SD/MMC cards can erase an arbitrarily large area up to and
including the whole card. When erasing a large area it may
be desirable to do it in smaller chunks for three reasons:
1. A single erase command will make all other I/O on the card
wait. This is not a problem if the whole card is being erased, but
erasing one partition will make I/O for another partition on the
same card wait for the duration of the erase - which could be a
several minutes.
2. To be able to inform the user of erase progress.
3. The erase timeout becomes too large to be very useful.
Because the erase timeout contains a margin which is multiplied by
the size of the erase area, the value can end up being several
minutes for large areas.
"erase_size" is not the most efficient unit to erase (especially for SD
where it is just one sector), hence "preferred_erase_size" provides a good
chunk size for erasing large areas.
For MMC, "preferred_erase_size" is the high-capacity erase size if a card
specifies one, otherwise it is based on the capacity of the card.
For SD, "preferred_erase_size" is the allocation unit size specified by
the card.
"preferred_erase_size" is in bytes.
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Cc: Kyungmin Park <kmpark@infradead.org>
Cc: Madhusudhan Chikkature <madhu.cr@ti.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Ben Gardiner <bengardiner@nanometrics.ca>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-12 05:17:46 +08:00
|
|
|
return 1;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(mmc_can_trim);
|
|
|
|
|
2011-10-18 08:34:04 +08:00
|
|
|
int mmc_can_discard(struct mmc_card *card)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* As there's no way to detect the discard support bit at v4.5
|
|
|
|
* use the s/w feature support filed.
|
|
|
|
*/
|
|
|
|
if (card->ext_csd.feature_support & MMC_DISCARD_FEATURE)
|
|
|
|
return 1;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(mmc_can_discard);
|
|
|
|
|
2011-10-14 13:15:48 +08:00
|
|
|
int mmc_can_sanitize(struct mmc_card *card)
|
|
|
|
{
|
2012-04-05 19:45:48 +08:00
|
|
|
if (!mmc_can_trim(card) && !mmc_can_erase(card))
|
|
|
|
return 0;
|
2011-10-14 13:15:48 +08:00
|
|
|
if (card->ext_csd.sec_feature_support & EXT_CSD_SEC_SANITIZE)
|
|
|
|
return 1;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
mmc: add erase, secure erase, trim and secure trim operations
SD/MMC cards tend to support an erase operation. In addition, eMMC v4.4
cards can support secure erase, trim and secure trim operations that are
all variants of the basic erase command.
SD/MMC device attributes "erase_size" and "preferred_erase_size" have been
added.
"erase_size" is the minimum size, in bytes, of an erase operation. For
MMC, "erase_size" is the erase group size reported by the card. Note that
"erase_size" does not apply to trim or secure trim operations where the
minimum size is always one 512 byte sector. For SD, "erase_size" is 512
if the card is block-addressed, 0 otherwise.
SD/MMC cards can erase an arbitrarily large area up to and
including the whole card. When erasing a large area it may
be desirable to do it in smaller chunks for three reasons:
1. A single erase command will make all other I/O on the card
wait. This is not a problem if the whole card is being erased, but
erasing one partition will make I/O for another partition on the
same card wait for the duration of the erase - which could be a
several minutes.
2. To be able to inform the user of erase progress.
3. The erase timeout becomes too large to be very useful.
Because the erase timeout contains a margin which is multiplied by
the size of the erase area, the value can end up being several
minutes for large areas.
"erase_size" is not the most efficient unit to erase (especially for SD
where it is just one sector), hence "preferred_erase_size" provides a good
chunk size for erasing large areas.
For MMC, "preferred_erase_size" is the high-capacity erase size if a card
specifies one, otherwise it is based on the capacity of the card.
For SD, "preferred_erase_size" is the allocation unit size specified by
the card.
"preferred_erase_size" is in bytes.
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Cc: Kyungmin Park <kmpark@infradead.org>
Cc: Madhusudhan Chikkature <madhu.cr@ti.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Ben Gardiner <bengardiner@nanometrics.ca>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-12 05:17:46 +08:00
|
|
|
int mmc_can_secure_erase_trim(struct mmc_card *card)
|
|
|
|
{
|
2014-06-18 19:18:07 +08:00
|
|
|
if ((card->ext_csd.sec_feature_support & EXT_CSD_SEC_ER_EN) &&
|
|
|
|
!(card->quirks & MMC_QUIRK_SEC_ERASE_TRIM_BROKEN))
|
mmc: add erase, secure erase, trim and secure trim operations
SD/MMC cards tend to support an erase operation. In addition, eMMC v4.4
cards can support secure erase, trim and secure trim operations that are
all variants of the basic erase command.
SD/MMC device attributes "erase_size" and "preferred_erase_size" have been
added.
"erase_size" is the minimum size, in bytes, of an erase operation. For
MMC, "erase_size" is the erase group size reported by the card. Note that
"erase_size" does not apply to trim or secure trim operations where the
minimum size is always one 512 byte sector. For SD, "erase_size" is 512
if the card is block-addressed, 0 otherwise.
SD/MMC cards can erase an arbitrarily large area up to and
including the whole card. When erasing a large area it may
be desirable to do it in smaller chunks for three reasons:
1. A single erase command will make all other I/O on the card
wait. This is not a problem if the whole card is being erased, but
erasing one partition will make I/O for another partition on the
same card wait for the duration of the erase - which could be a
several minutes.
2. To be able to inform the user of erase progress.
3. The erase timeout becomes too large to be very useful.
Because the erase timeout contains a margin which is multiplied by
the size of the erase area, the value can end up being several
minutes for large areas.
"erase_size" is not the most efficient unit to erase (especially for SD
where it is just one sector), hence "preferred_erase_size" provides a good
chunk size for erasing large areas.
For MMC, "preferred_erase_size" is the high-capacity erase size if a card
specifies one, otherwise it is based on the capacity of the card.
For SD, "preferred_erase_size" is the allocation unit size specified by
the card.
"preferred_erase_size" is in bytes.
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Cc: Kyungmin Park <kmpark@infradead.org>
Cc: Madhusudhan Chikkature <madhu.cr@ti.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Ben Gardiner <bengardiner@nanometrics.ca>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-12 05:17:46 +08:00
|
|
|
return 1;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(mmc_can_secure_erase_trim);
|
|
|
|
|
|
|
|
int mmc_erase_group_aligned(struct mmc_card *card, unsigned int from,
|
|
|
|
unsigned int nr)
|
|
|
|
{
|
|
|
|
if (!card->erase_size)
|
|
|
|
return 0;
|
|
|
|
if (from % card->erase_size || nr % card->erase_size)
|
|
|
|
return 0;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(mmc_erase_group_aligned);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2011-06-28 22:16:02 +08:00
|
|
|
static unsigned int mmc_do_calc_max_discard(struct mmc_card *card,
|
|
|
|
unsigned int arg)
|
|
|
|
{
|
|
|
|
struct mmc_host *host = card->host;
|
2016-07-25 16:48:39 +08:00
|
|
|
unsigned int max_discard, x, y, qty = 0, max_qty, min_qty, timeout;
|
2011-06-28 22:16:02 +08:00
|
|
|
unsigned int last_timeout = 0;
|
2016-07-27 06:04:03 +08:00
|
|
|
unsigned int max_busy_timeout = host->max_busy_timeout ?
|
|
|
|
host->max_busy_timeout : MMC_ERASE_TIMEOUT_MS;
|
2011-06-28 22:16:02 +08:00
|
|
|
|
2016-07-25 16:48:39 +08:00
|
|
|
if (card->erase_shift) {
|
2011-06-28 22:16:02 +08:00
|
|
|
max_qty = UINT_MAX >> card->erase_shift;
|
2016-07-25 16:48:39 +08:00
|
|
|
min_qty = card->pref_erase >> card->erase_shift;
|
|
|
|
} else if (mmc_card_sd(card)) {
|
2011-06-28 22:16:02 +08:00
|
|
|
max_qty = UINT_MAX;
|
2016-07-25 16:48:39 +08:00
|
|
|
min_qty = card->pref_erase;
|
|
|
|
} else {
|
2011-06-28 22:16:02 +08:00
|
|
|
max_qty = UINT_MAX / card->erase_size;
|
2016-07-25 16:48:39 +08:00
|
|
|
min_qty = card->pref_erase / card->erase_size;
|
|
|
|
}
|
2011-06-28 22:16:02 +08:00
|
|
|
|
2016-07-25 16:48:39 +08:00
|
|
|
/*
|
|
|
|
* We should not only use 'host->max_busy_timeout' as the limitation
|
|
|
|
* when deciding the max discard sectors. We should set a balance value
|
|
|
|
* to improve the erase speed, and it can not get too long timeout at
|
|
|
|
* the same time.
|
|
|
|
*
|
|
|
|
* Here we set 'card->pref_erase' as the minimal discard sectors no
|
|
|
|
* matter what size of 'host->max_busy_timeout', but if the
|
|
|
|
* 'host->max_busy_timeout' is large enough for more discard sectors,
|
|
|
|
* then we can continue to increase the max discard sectors until we
|
2016-07-27 06:04:03 +08:00
|
|
|
* get a balance value. In cases when the 'host->max_busy_timeout'
|
|
|
|
* isn't specified, use the default max erase timeout.
|
2016-07-25 16:48:39 +08:00
|
|
|
*/
|
2011-06-28 22:16:02 +08:00
|
|
|
do {
|
|
|
|
y = 0;
|
|
|
|
for (x = 1; x && x <= max_qty && max_qty - x >= qty; x <<= 1) {
|
|
|
|
timeout = mmc_erase_timeout(card, arg, qty + x);
|
2016-07-25 16:48:39 +08:00
|
|
|
|
2016-07-27 06:04:03 +08:00
|
|
|
if (qty + x > min_qty && timeout > max_busy_timeout)
|
2011-06-28 22:16:02 +08:00
|
|
|
break;
|
2016-07-25 16:48:39 +08:00
|
|
|
|
2011-06-28 22:16:02 +08:00
|
|
|
if (timeout < last_timeout)
|
|
|
|
break;
|
|
|
|
last_timeout = timeout;
|
|
|
|
y = x;
|
|
|
|
}
|
|
|
|
qty += y;
|
|
|
|
} while (y);
|
|
|
|
|
|
|
|
if (!qty)
|
|
|
|
return 0;
|
|
|
|
|
2015-06-23 17:43:52 +08:00
|
|
|
/*
|
|
|
|
* When specifying a sector range to trim, chances are we might cross
|
|
|
|
* an erase-group boundary even if the amount of sectors is less than
|
|
|
|
* one erase-group.
|
|
|
|
* If we can only fit one erase-group in the controller timeout budget,
|
|
|
|
* we have to care that erase-group boundaries are not crossed by a
|
|
|
|
* single trim operation. We flag that special case with "eg_boundary".
|
|
|
|
* In all other cases we can just decrement qty and pretend that we
|
|
|
|
* always touch (qty + 1) erase-groups as a simple optimization.
|
|
|
|
*/
|
2011-06-28 22:16:02 +08:00
|
|
|
if (qty == 1)
|
2015-06-23 17:43:52 +08:00
|
|
|
card->eg_boundary = 1;
|
|
|
|
else
|
|
|
|
qty--;
|
2011-06-28 22:16:02 +08:00
|
|
|
|
|
|
|
/* Convert qty to sectors */
|
|
|
|
if (card->erase_shift)
|
2015-06-23 17:43:52 +08:00
|
|
|
max_discard = qty << card->erase_shift;
|
2011-06-28 22:16:02 +08:00
|
|
|
else if (mmc_card_sd(card))
|
2015-06-23 17:43:52 +08:00
|
|
|
max_discard = qty + 1;
|
2011-06-28 22:16:02 +08:00
|
|
|
else
|
2015-06-23 17:43:52 +08:00
|
|
|
max_discard = qty * card->erase_size;
|
2011-06-28 22:16:02 +08:00
|
|
|
|
|
|
|
return max_discard;
|
|
|
|
}
|
|
|
|
|
|
|
|
unsigned int mmc_calc_max_discard(struct mmc_card *card)
|
|
|
|
{
|
|
|
|
struct mmc_host *host = card->host;
|
|
|
|
unsigned int max_discard, max_trim;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Without erase_group_def set, MMC erase timeout depends on clock
|
|
|
|
* frequence which can change. In that case, the best choice is
|
|
|
|
* just the preferred erase size.
|
|
|
|
*/
|
|
|
|
if (mmc_card_mmc(card) && !(card->ext_csd.erase_group_def & 1))
|
|
|
|
return card->pref_erase;
|
|
|
|
|
|
|
|
max_discard = mmc_do_calc_max_discard(card, MMC_ERASE_ARG);
|
2019-03-01 00:18:33 +08:00
|
|
|
if (mmc_can_trim(card)) {
|
2011-06-28 22:16:02 +08:00
|
|
|
max_trim = mmc_do_calc_max_discard(card, MMC_TRIM_ARG);
|
2019-03-01 00:18:33 +08:00
|
|
|
if (max_trim < max_discard || max_discard == 0)
|
2011-06-28 22:16:02 +08:00
|
|
|
max_discard = max_trim;
|
|
|
|
} else if (max_discard < card->erase_size) {
|
|
|
|
max_discard = 0;
|
|
|
|
}
|
|
|
|
pr_debug("%s: calculated max. discard sectors %u for timeout %u ms\n",
|
2016-07-27 06:04:03 +08:00
|
|
|
mmc_hostname(host), max_discard, host->max_busy_timeout ?
|
|
|
|
host->max_busy_timeout : MMC_ERASE_TIMEOUT_MS);
|
2011-06-28 22:16:02 +08:00
|
|
|
return max_discard;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(mmc_calc_max_discard);
|
|
|
|
|
2017-04-25 02:41:55 +08:00
|
|
|
bool mmc_card_is_blockaddr(struct mmc_card *card)
|
|
|
|
{
|
|
|
|
return card ? mmc_card_blockaddr(card) : false;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(mmc_card_is_blockaddr);
|
|
|
|
|
2010-08-24 18:20:26 +08:00
|
|
|
int mmc_set_blocklen(struct mmc_card *card, unsigned int blocklen)
|
|
|
|
{
|
2016-12-19 19:51:18 +08:00
|
|
|
struct mmc_command cmd = {};
|
2010-08-24 18:20:26 +08:00
|
|
|
|
2016-09-21 09:43:49 +08:00
|
|
|
if (mmc_card_blockaddr(card) || mmc_card_ddr52(card) ||
|
|
|
|
mmc_card_hs400(card) || mmc_card_hs400es(card))
|
2010-08-24 18:20:26 +08:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
cmd.opcode = MMC_SET_BLOCKLEN;
|
|
|
|
cmd.arg = blocklen;
|
|
|
|
cmd.flags = MMC_RSP_SPI_R1 | MMC_RSP_R1 | MMC_CMD_AC;
|
|
|
|
return mmc_wait_for_cmd(card->host, &cmd, 5);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(mmc_set_blocklen);
|
|
|
|
|
2011-08-29 21:42:11 +08:00
|
|
|
static void mmc_hw_reset_for_init(struct mmc_host *host)
|
|
|
|
{
|
2017-05-09 05:52:04 +08:00
|
|
|
mmc_pwrseq_reset(host);
|
|
|
|
|
2011-08-29 21:42:11 +08:00
|
|
|
if (!(host->caps & MMC_CAP_HW_RESET) || !host->ops->hw_reset)
|
|
|
|
return;
|
|
|
|
host->ops->hw_reset(host);
|
|
|
|
}
|
|
|
|
|
2015-01-12 22:38:04 +08:00
|
|
|
int mmc_hw_reset(struct mmc_host *host)
|
2011-08-29 21:42:11 +08:00
|
|
|
{
|
2015-01-12 22:38:05 +08:00
|
|
|
int ret;
|
2011-08-29 21:42:11 +08:00
|
|
|
|
2015-01-12 22:38:05 +08:00
|
|
|
if (!host->card)
|
2011-08-29 21:42:11 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
2015-01-12 22:38:05 +08:00
|
|
|
mmc_bus_get(host);
|
2018-04-05 19:24:43 +08:00
|
|
|
if (!host->bus_ops || host->bus_dead || !host->bus_ops->hw_reset) {
|
2015-01-12 22:38:05 +08:00
|
|
|
mmc_bus_put(host);
|
2011-08-29 21:42:11 +08:00
|
|
|
return -EOPNOTSUPP;
|
|
|
|
}
|
|
|
|
|
2018-04-05 19:24:43 +08:00
|
|
|
ret = host->bus_ops->hw_reset(host);
|
2015-01-12 22:38:05 +08:00
|
|
|
mmc_bus_put(host);
|
2011-08-29 21:42:11 +08:00
|
|
|
|
mmc: core: Re-work HW reset for SDIO cards
It have turned out that it's not a good idea to unconditionally do a power
cycle and then to re-initialize the SDIO card, as currently done through
mmc_hw_reset() -> mmc_sdio_hw_reset(). This because there may be multiple
SDIO func drivers probed, who also shares the same SDIO card.
To address these scenarios, one may be tempted to use a notification
mechanism, as to allow the core to inform each of the probed func drivers,
about an ongoing HW reset. However, supporting such an operation from the
func driver point of view, may not be entirely trivial.
Therefore, let's use a more simplistic approach to solve the problem, by
instead forcing the card to be removed and re-detected, via scheduling a
rescan-work. In this way, we can rely on existing infrastructure, as the
func driver's ->remove() and ->probe() callbacks, becomes invoked to deal
with the cleanup and the re-initialization.
This solution may be considered as rather heavy, especially if a func
driver doesn't share its card with other func drivers. To address this,
let's keep the current immediate HW reset option as well, but run it only
when there is one func driver probed for the card.
Finally, to allow the caller of mmc_hw_reset(), to understand if the reset
is being asynchronously managed from a scheduled work, it returns 1
(propagated from mmc_sdio_hw_reset()). If the HW reset is executed
successfully and synchronously it returns 0, which maintains the existing
behaviour.
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Douglas Anderson <dianders@chromium.org>
Cc: stable@vger.kernel.org # v5.4+
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2019-10-17 21:25:36 +08:00
|
|
|
if (ret < 0)
|
2018-04-05 19:24:43 +08:00
|
|
|
pr_warn("%s: tried to HW reset card, got error %d\n",
|
2016-04-02 07:04:22 +08:00
|
|
|
mmc_hostname(host), ret);
|
2011-08-29 21:42:11 +08:00
|
|
|
|
2015-01-12 22:38:05 +08:00
|
|
|
return ret;
|
2011-08-29 21:42:11 +08:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(mmc_hw_reset);
|
|
|
|
|
2018-04-05 19:42:00 +08:00
|
|
|
int mmc_sw_reset(struct mmc_host *host)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (!host->card)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
mmc_bus_get(host);
|
|
|
|
if (!host->bus_ops || host->bus_dead || !host->bus_ops->sw_reset) {
|
|
|
|
mmc_bus_put(host);
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
}
|
|
|
|
|
|
|
|
ret = host->bus_ops->sw_reset(host);
|
|
|
|
mmc_bus_put(host);
|
|
|
|
|
|
|
|
if (ret)
|
|
|
|
pr_warn("%s: tried to SW reset card, got error %d\n",
|
|
|
|
mmc_hostname(host), ret);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(mmc_sw_reset);
|
|
|
|
|
2011-01-04 02:36:56 +08:00
|
|
|
static int mmc_rescan_try_freq(struct mmc_host *host, unsigned freq)
|
|
|
|
{
|
|
|
|
host->f_init = freq;
|
|
|
|
|
2017-07-19 15:55:46 +08:00
|
|
|
pr_debug("%s: %s: trying to init card at %u Hz\n",
|
2011-01-04 02:36:56 +08:00
|
|
|
mmc_hostname(host), __func__, host->f_init);
|
2017-07-19 15:55:46 +08:00
|
|
|
|
2013-09-12 20:36:53 +08:00
|
|
|
mmc_power_up(host, host->ocr_avail);
|
2011-02-14 15:12:28 +08:00
|
|
|
|
2011-08-29 21:42:11 +08:00
|
|
|
/*
|
|
|
|
* Some eMMCs (with VCCQ always on) may not be reset after power up, so
|
|
|
|
* do a hardware reset if possible.
|
|
|
|
*/
|
|
|
|
mmc_hw_reset_for_init(host);
|
|
|
|
|
2011-02-14 15:12:28 +08:00
|
|
|
/*
|
|
|
|
* sdio_reset sends CMD52 to reset card. Since we do not know
|
|
|
|
* if the card is being re-initialized, just send it. CMD52
|
|
|
|
* should be ignored by SD/eMMC cards.
|
2015-11-25 22:39:51 +08:00
|
|
|
* Skip it if we already know that we do not support SDIO commands
|
2011-02-14 15:12:28 +08:00
|
|
|
*/
|
2015-11-25 22:39:51 +08:00
|
|
|
if (!(host->caps2 & MMC_CAP2_NO_SDIO))
|
|
|
|
sdio_reset(host);
|
|
|
|
|
2011-01-04 02:36:56 +08:00
|
|
|
mmc_go_idle(host);
|
|
|
|
|
2016-06-21 21:12:46 +08:00
|
|
|
if (!(host->caps2 & MMC_CAP2_NO_SD))
|
|
|
|
mmc_send_if_cond(host, host->ocr_avail);
|
2011-01-04 02:36:56 +08:00
|
|
|
|
|
|
|
/* Order's important: probe SDIO, then SD, then MMC */
|
2015-11-25 22:39:51 +08:00
|
|
|
if (!(host->caps2 & MMC_CAP2_NO_SDIO))
|
|
|
|
if (!mmc_attach_sdio(host))
|
|
|
|
return 0;
|
|
|
|
|
2016-06-21 21:12:46 +08:00
|
|
|
if (!(host->caps2 & MMC_CAP2_NO_SD))
|
|
|
|
if (!mmc_attach_sd(host))
|
|
|
|
return 0;
|
|
|
|
|
2016-07-01 15:45:28 +08:00
|
|
|
if (!(host->caps2 & MMC_CAP2_NO_MMC))
|
|
|
|
if (!mmc_attach_mmc(host))
|
|
|
|
return 0;
|
2011-01-04 02:36:56 +08:00
|
|
|
|
|
|
|
mmc_power_off(host);
|
|
|
|
return -EIO;
|
|
|
|
}
|
|
|
|
|
2011-11-28 22:22:00 +08:00
|
|
|
int _mmc_detect_card_removed(struct mmc_host *host)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (!host->card || mmc_card_removed(host->card))
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
ret = host->bus_ops->alive(host);
|
2013-02-28 15:29:29 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Card detect status and alive check may be out of sync if card is
|
|
|
|
* removed slowly, when card detect switch changes while card/slot
|
|
|
|
* pads are still contacted in hardware (refer to "SD Card Mechanical
|
|
|
|
* Addendum, Appendix C: Card Detection Switch"). So reschedule a
|
|
|
|
* detect work 200ms later for this case.
|
|
|
|
*/
|
|
|
|
if (!ret && host->ops->get_cd && !host->ops->get_cd(host)) {
|
|
|
|
mmc_detect_change(host, msecs_to_jiffies(200));
|
|
|
|
pr_debug("%s: card removed too slowly\n", mmc_hostname(host));
|
|
|
|
}
|
|
|
|
|
2011-11-28 22:22:00 +08:00
|
|
|
if (ret) {
|
|
|
|
mmc_card_set_removed(host->card);
|
|
|
|
pr_debug("%s: card remove detected\n", mmc_hostname(host));
|
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
int mmc_detect_card_removed(struct mmc_host *host)
|
|
|
|
{
|
|
|
|
struct mmc_card *card = host->card;
|
2012-02-06 17:42:39 +08:00
|
|
|
int ret;
|
2011-11-28 22:22:00 +08:00
|
|
|
|
|
|
|
WARN_ON(!host->claimed);
|
2012-02-06 17:42:39 +08:00
|
|
|
|
|
|
|
if (!card)
|
|
|
|
return 1;
|
|
|
|
|
2016-01-29 07:52:57 +08:00
|
|
|
if (!mmc_card_is_removable(host))
|
2015-11-05 23:21:39 +08:00
|
|
|
return 0;
|
|
|
|
|
2012-02-06 17:42:39 +08:00
|
|
|
ret = mmc_card_removed(card);
|
2011-11-28 22:22:00 +08:00
|
|
|
/*
|
|
|
|
* The card will be considered unchanged unless we have been asked to
|
|
|
|
* detect a change or host requires polling to provide card detection.
|
|
|
|
*/
|
2013-04-18 17:02:07 +08:00
|
|
|
if (!host->detect_change && !(host->caps & MMC_CAP_NEEDS_POLL))
|
2012-02-06 17:42:39 +08:00
|
|
|
return ret;
|
2011-11-28 22:22:00 +08:00
|
|
|
|
|
|
|
host->detect_change = 0;
|
2012-02-06 17:42:39 +08:00
|
|
|
if (!ret) {
|
|
|
|
ret = _mmc_detect_card_removed(host);
|
2013-04-18 17:02:07 +08:00
|
|
|
if (ret && (host->caps & MMC_CAP_NEEDS_POLL)) {
|
2012-02-06 17:42:39 +08:00
|
|
|
/*
|
|
|
|
* Schedule a detect work as soon as possible to let a
|
|
|
|
* rescan handle the card removal.
|
|
|
|
*/
|
|
|
|
cancel_delayed_work(&host->detect);
|
2013-09-20 17:02:35 +08:00
|
|
|
_mmc_detect_change(host, 0, false);
|
2012-02-06 17:42:39 +08:00
|
|
|
}
|
|
|
|
}
|
2011-11-28 22:22:00 +08:00
|
|
|
|
2012-02-06 17:42:39 +08:00
|
|
|
return ret;
|
2011-11-28 22:22:00 +08:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(mmc_detect_card_removed);
|
|
|
|
|
2007-05-19 20:06:24 +08:00
|
|
|
void mmc_rescan(struct work_struct *work)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2006-11-22 22:57:56 +08:00
|
|
|
struct mmc_host *host =
|
|
|
|
container_of(work, struct mmc_host, detect.work);
|
2010-09-06 09:37:19 +08:00
|
|
|
int i;
|
mmc: fix all hangs related to mmc/sd card insert/removal during suspend/resume
If you don't use CONFIG_MMC_UNSAFE_RESUME, as soon as you attempt to
suspend, the card will be removed, therefore this patch doesn't change the
behavior of this option.
However the removal will be done by pm notifier, which runs while
userspace is still not frozen and thus can freely use del_gendisk, without
the risk of deadlock which would happen otherwise.
Card detect workqueue is now disabled while userspace is frozen, Therefore
if you do use CONFIG_MMC_UNSAFE_RESUME, and remove the card during
suspend, the removal will be detected as soon as userspace is unfrozen,
again at the moment it is safe to call del_gendisk.
Tested with and without CONFIG_MMC_UNSAFE_RESUME with suspend and hibernate.
[akpm@linux-foundation.org: clean up function prototype]
[akpm@linux-foundation.org: fix CONFIG_PM-n linkage, small cleanups]
[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
Cc: David Brownell <david-b@pacbell.net>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-11 09:01:41 +08:00
|
|
|
|
2011-01-04 02:36:56 +08:00
|
|
|
if (host->rescan_disable)
|
mmc: fix all hangs related to mmc/sd card insert/removal during suspend/resume
If you don't use CONFIG_MMC_UNSAFE_RESUME, as soon as you attempt to
suspend, the card will be removed, therefore this patch doesn't change the
behavior of this option.
However the removal will be done by pm notifier, which runs while
userspace is still not frozen and thus can freely use del_gendisk, without
the risk of deadlock which would happen otherwise.
Card detect workqueue is now disabled while userspace is frozen, Therefore
if you do use CONFIG_MMC_UNSAFE_RESUME, and remove the card during
suspend, the removal will be detected as soon as userspace is unfrozen,
again at the moment it is safe to call del_gendisk.
Tested with and without CONFIG_MMC_UNSAFE_RESUME with suspend and hibernate.
[akpm@linux-foundation.org: clean up function prototype]
[akpm@linux-foundation.org: fix CONFIG_PM-n linkage, small cleanups]
[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
Cc: David Brownell <david-b@pacbell.net>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-11 09:01:41 +08:00
|
|
|
return;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2012-08-23 19:40:55 +08:00
|
|
|
/* If there is a non-removable card registered, only scan once */
|
2016-01-29 07:52:57 +08:00
|
|
|
if (!mmc_card_is_removable(host) && host->rescan_entered)
|
2012-08-23 19:40:55 +08:00
|
|
|
return;
|
|
|
|
host->rescan_entered = 1;
|
|
|
|
|
2015-11-05 23:08:07 +08:00
|
|
|
if (host->trigger_card_event && host->ops->card_event) {
|
2015-11-05 23:08:08 +08:00
|
|
|
mmc_claim_host(host);
|
2015-11-05 23:08:07 +08:00
|
|
|
host->ops->card_event(host);
|
2015-11-05 23:08:08 +08:00
|
|
|
mmc_release_host(host);
|
2015-11-05 23:08:07 +08:00
|
|
|
host->trigger_card_event = false;
|
|
|
|
}
|
|
|
|
|
2006-12-31 07:11:32 +08:00
|
|
|
mmc_bus_get(host);
|
2007-01-04 02:47:29 +08:00
|
|
|
|
2019-10-10 21:54:37 +08:00
|
|
|
/* Verify a registered card to be functional, else remove it. */
|
|
|
|
if (host->bus_ops && !host->bus_dead)
|
2009-03-31 22:51:21 +08:00
|
|
|
host->bus_ops->detect(host);
|
|
|
|
|
2011-11-28 22:22:00 +08:00
|
|
|
host->detect_change = 0;
|
|
|
|
|
2011-01-05 01:20:22 +08:00
|
|
|
/*
|
|
|
|
* Let mmc_bus_put() free the bus/bus_ops if we've found that
|
|
|
|
* the card is no longer present.
|
|
|
|
*/
|
2009-03-31 22:51:21 +08:00
|
|
|
mmc_bus_put(host);
|
|
|
|
mmc_bus_get(host);
|
|
|
|
|
|
|
|
/* if there still is a card present, stop here */
|
|
|
|
if (host->bus_ops != NULL) {
|
2006-12-31 07:11:32 +08:00
|
|
|
mmc_bus_put(host);
|
2009-03-31 22:51:21 +08:00
|
|
|
goto out;
|
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2009-03-31 22:51:21 +08:00
|
|
|
/*
|
|
|
|
* Only we can add a new handler, so it's safe to
|
|
|
|
* release the lock here.
|
|
|
|
*/
|
|
|
|
mmc_bus_put(host);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2015-11-05 23:08:08 +08:00
|
|
|
mmc_claim_host(host);
|
2016-01-29 07:52:57 +08:00
|
|
|
if (mmc_card_is_removable(host) && host->ops->get_cd &&
|
2013-12-05 21:34:46 +08:00
|
|
|
host->ops->get_cd(host) == 0) {
|
2012-05-09 22:15:26 +08:00
|
|
|
mmc_power_off(host);
|
|
|
|
mmc_release_host(host);
|
2009-03-31 22:51:21 +08:00
|
|
|
goto out;
|
2012-05-09 22:15:26 +08:00
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2010-09-06 09:37:19 +08:00
|
|
|
for (i = 0; i < ARRAY_SIZE(freqs); i++) {
|
2020-01-02 18:54:58 +08:00
|
|
|
unsigned int freq = freqs[i];
|
|
|
|
if (freq > host->f_max) {
|
|
|
|
if (i + 1 < ARRAY_SIZE(freqs))
|
|
|
|
continue;
|
|
|
|
freq = host->f_max;
|
|
|
|
}
|
|
|
|
if (!mmc_rescan_try_freq(host, max(freq, host->f_min)))
|
2011-01-04 02:36:56 +08:00
|
|
|
break;
|
2011-05-12 16:18:59 +08:00
|
|
|
if (freqs[i] <= host->f_min)
|
2011-01-04 02:36:56 +08:00
|
|
|
break;
|
2010-09-06 09:37:19 +08:00
|
|
|
}
|
2011-01-04 02:36:56 +08:00
|
|
|
mmc_release_host(host);
|
|
|
|
|
|
|
|
out:
|
2008-06-17 22:17:15 +08:00
|
|
|
if (host->caps & MMC_CAP_NEEDS_POLL)
|
|
|
|
mmc_schedule_delayed_work(&host->detect, HZ);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2007-05-19 20:06:24 +08:00
|
|
|
void mmc_start_host(struct mmc_host *host)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2020-01-02 18:54:58 +08:00
|
|
|
host->f_init = max(min(freqs[0], host->f_max), host->f_min);
|
2012-06-14 16:17:39 +08:00
|
|
|
host->rescan_disable = 0;
|
2015-09-11 20:41:55 +08:00
|
|
|
|
mmc: core: Don't power off the card when starting the host
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: Ulf Hansson <ulf.hansson@linaro.org>
2016-10-13 19:37:40 +08:00
|
|
|
if (!(host->caps2 & MMC_CAP2_NO_PRESCAN_POWERUP)) {
|
|
|
|
mmc_claim_host(host);
|
2013-09-12 20:36:53 +08:00
|
|
|
mmc_power_up(host, host->ocr_avail);
|
mmc: core: Don't power off the card when starting the host
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: Ulf Hansson <ulf.hansson@linaro.org>
2016-10-13 19:37:40 +08:00
|
|
|
mmc_release_host(host);
|
|
|
|
}
|
2015-09-11 20:41:55 +08:00
|
|
|
|
2014-03-10 21:02:41 +08:00
|
|
|
mmc_gpiod_request_cd_irq(host);
|
2013-09-20 17:02:35 +08:00
|
|
|
_mmc_detect_change(host, 0, false);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2007-05-19 20:06:24 +08:00
|
|
|
void mmc_stop_host(struct mmc_host *host)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2017-06-13 20:07:51 +08:00
|
|
|
if (host->slot.cd_irq >= 0) {
|
2018-02-27 20:51:25 +08:00
|
|
|
mmc_gpio_set_cd_wake(host, false);
|
2014-03-10 21:02:41 +08:00
|
|
|
disable_irq(host->slot.cd_irq);
|
2017-06-13 20:07:51 +08:00
|
|
|
}
|
2007-02-12 03:43:19 +08:00
|
|
|
|
2012-06-14 16:17:39 +08:00
|
|
|
host->rescan_disable = 1;
|
2010-11-12 00:32:25 +08:00
|
|
|
cancel_delayed_work_sync(&host->detect);
|
2007-02-12 03:43:19 +08:00
|
|
|
|
2010-03-06 05:43:31 +08:00
|
|
|
/* clear pm flags now and let card drivers set them as needed */
|
|
|
|
host->pm_flags = 0;
|
|
|
|
|
2006-12-31 07:11:32 +08:00
|
|
|
mmc_bus_get(host);
|
|
|
|
if (host->bus_ops && !host->bus_dead) {
|
2012-01-04 22:28:45 +08:00
|
|
|
/* Calling bus_ops->remove() with a claimed host can deadlock */
|
2013-06-10 23:03:36 +08:00
|
|
|
host->bus_ops->remove(host);
|
2006-12-31 07:11:32 +08:00
|
|
|
mmc_claim_host(host);
|
|
|
|
mmc_detach_bus(host);
|
2011-09-22 02:08:13 +08:00
|
|
|
mmc_power_off(host);
|
2006-12-31 07:11:32 +08:00
|
|
|
mmc_release_host(host);
|
2009-09-23 07:44:36 +08:00
|
|
|
mmc_bus_put(host);
|
|
|
|
return;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
2006-12-31 07:11:32 +08:00
|
|
|
mmc_bus_put(host);
|
|
|
|
|
2015-09-11 20:41:55 +08:00
|
|
|
mmc_claim_host(host);
|
2005-04-17 06:20:36 +08:00
|
|
|
mmc_power_off(host);
|
2015-09-11 20:41:55 +08:00
|
|
|
mmc_release_host(host);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2015-11-05 23:11:12 +08:00
|
|
|
#ifdef CONFIG_PM_SLEEP
|
mmc: fix all hangs related to mmc/sd card insert/removal during suspend/resume
If you don't use CONFIG_MMC_UNSAFE_RESUME, as soon as you attempt to
suspend, the card will be removed, therefore this patch doesn't change the
behavior of this option.
However the removal will be done by pm notifier, which runs while
userspace is still not frozen and thus can freely use del_gendisk, without
the risk of deadlock which would happen otherwise.
Card detect workqueue is now disabled while userspace is frozen, Therefore
if you do use CONFIG_MMC_UNSAFE_RESUME, and remove the card during
suspend, the removal will be detected as soon as userspace is unfrozen,
again at the moment it is safe to call del_gendisk.
Tested with and without CONFIG_MMC_UNSAFE_RESUME with suspend and hibernate.
[akpm@linux-foundation.org: clean up function prototype]
[akpm@linux-foundation.org: fix CONFIG_PM-n linkage, small cleanups]
[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
Cc: David Brownell <david-b@pacbell.net>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-11 09:01:41 +08:00
|
|
|
/* Do the card removal on suspend if card is assumed removeable
|
|
|
|
* Do that in pm notifier while userspace isn't yet frozen, so we will be able
|
|
|
|
to sync the card.
|
|
|
|
*/
|
2015-11-05 23:11:12 +08:00
|
|
|
static int mmc_pm_notify(struct notifier_block *notify_block,
|
|
|
|
unsigned long mode, void *unused)
|
mmc: fix all hangs related to mmc/sd card insert/removal during suspend/resume
If you don't use CONFIG_MMC_UNSAFE_RESUME, as soon as you attempt to
suspend, the card will be removed, therefore this patch doesn't change the
behavior of this option.
However the removal will be done by pm notifier, which runs while
userspace is still not frozen and thus can freely use del_gendisk, without
the risk of deadlock which would happen otherwise.
Card detect workqueue is now disabled while userspace is frozen, Therefore
if you do use CONFIG_MMC_UNSAFE_RESUME, and remove the card during
suspend, the removal will be detected as soon as userspace is unfrozen,
again at the moment it is safe to call del_gendisk.
Tested with and without CONFIG_MMC_UNSAFE_RESUME with suspend and hibernate.
[akpm@linux-foundation.org: clean up function prototype]
[akpm@linux-foundation.org: fix CONFIG_PM-n linkage, small cleanups]
[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
Cc: David Brownell <david-b@pacbell.net>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-11 09:01:41 +08:00
|
|
|
{
|
|
|
|
struct mmc_host *host = container_of(
|
|
|
|
notify_block, struct mmc_host, pm_notify);
|
|
|
|
unsigned long flags;
|
2013-06-10 23:03:37 +08:00
|
|
|
int err = 0;
|
mmc: fix all hangs related to mmc/sd card insert/removal during suspend/resume
If you don't use CONFIG_MMC_UNSAFE_RESUME, as soon as you attempt to
suspend, the card will be removed, therefore this patch doesn't change the
behavior of this option.
However the removal will be done by pm notifier, which runs while
userspace is still not frozen and thus can freely use del_gendisk, without
the risk of deadlock which would happen otherwise.
Card detect workqueue is now disabled while userspace is frozen, Therefore
if you do use CONFIG_MMC_UNSAFE_RESUME, and remove the card during
suspend, the removal will be detected as soon as userspace is unfrozen,
again at the moment it is safe to call del_gendisk.
Tested with and without CONFIG_MMC_UNSAFE_RESUME with suspend and hibernate.
[akpm@linux-foundation.org: clean up function prototype]
[akpm@linux-foundation.org: fix CONFIG_PM-n linkage, small cleanups]
[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
Cc: David Brownell <david-b@pacbell.net>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-11 09:01:41 +08:00
|
|
|
|
|
|
|
switch (mode) {
|
|
|
|
case PM_HIBERNATION_PREPARE:
|
|
|
|
case PM_SUSPEND_PREPARE:
|
2015-04-23 18:43:43 +08:00
|
|
|
case PM_RESTORE_PREPARE:
|
mmc: fix all hangs related to mmc/sd card insert/removal during suspend/resume
If you don't use CONFIG_MMC_UNSAFE_RESUME, as soon as you attempt to
suspend, the card will be removed, therefore this patch doesn't change the
behavior of this option.
However the removal will be done by pm notifier, which runs while
userspace is still not frozen and thus can freely use del_gendisk, without
the risk of deadlock which would happen otherwise.
Card detect workqueue is now disabled while userspace is frozen, Therefore
if you do use CONFIG_MMC_UNSAFE_RESUME, and remove the card during
suspend, the removal will be detected as soon as userspace is unfrozen,
again at the moment it is safe to call del_gendisk.
Tested with and without CONFIG_MMC_UNSAFE_RESUME with suspend and hibernate.
[akpm@linux-foundation.org: clean up function prototype]
[akpm@linux-foundation.org: fix CONFIG_PM-n linkage, small cleanups]
[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
Cc: David Brownell <david-b@pacbell.net>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-11 09:01:41 +08:00
|
|
|
spin_lock_irqsave(&host->lock, flags);
|
|
|
|
host->rescan_disable = 1;
|
|
|
|
spin_unlock_irqrestore(&host->lock, flags);
|
|
|
|
cancel_delayed_work_sync(&host->detect);
|
|
|
|
|
2013-06-10 23:03:37 +08:00
|
|
|
if (!host->bus_ops)
|
|
|
|
break;
|
|
|
|
|
|
|
|
/* Validate prerequisites for suspend */
|
|
|
|
if (host->bus_ops->pre_suspend)
|
|
|
|
err = host->bus_ops->pre_suspend(host);
|
2013-10-31 06:15:30 +08:00
|
|
|
if (!err)
|
mmc: fix all hangs related to mmc/sd card insert/removal during suspend/resume
If you don't use CONFIG_MMC_UNSAFE_RESUME, as soon as you attempt to
suspend, the card will be removed, therefore this patch doesn't change the
behavior of this option.
However the removal will be done by pm notifier, which runs while
userspace is still not frozen and thus can freely use del_gendisk, without
the risk of deadlock which would happen otherwise.
Card detect workqueue is now disabled while userspace is frozen, Therefore
if you do use CONFIG_MMC_UNSAFE_RESUME, and remove the card during
suspend, the removal will be detected as soon as userspace is unfrozen,
again at the moment it is safe to call del_gendisk.
Tested with and without CONFIG_MMC_UNSAFE_RESUME with suspend and hibernate.
[akpm@linux-foundation.org: clean up function prototype]
[akpm@linux-foundation.org: fix CONFIG_PM-n linkage, small cleanups]
[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
Cc: David Brownell <david-b@pacbell.net>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-11 09:01:41 +08:00
|
|
|
break;
|
|
|
|
|
2017-12-12 18:49:02 +08:00
|
|
|
if (!mmc_card_is_removable(host)) {
|
|
|
|
dev_warn(mmc_dev(host),
|
|
|
|
"pre_suspend failed for non-removable host: "
|
|
|
|
"%d\n", err);
|
|
|
|
/* Avoid removing non-removable hosts */
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2012-01-04 22:28:45 +08:00
|
|
|
/* Calling bus_ops->remove() with a claimed host can deadlock */
|
2013-06-10 23:03:36 +08:00
|
|
|
host->bus_ops->remove(host);
|
2012-01-04 22:28:45 +08:00
|
|
|
mmc_claim_host(host);
|
mmc: fix all hangs related to mmc/sd card insert/removal during suspend/resume
If you don't use CONFIG_MMC_UNSAFE_RESUME, as soon as you attempt to
suspend, the card will be removed, therefore this patch doesn't change the
behavior of this option.
However the removal will be done by pm notifier, which runs while
userspace is still not frozen and thus can freely use del_gendisk, without
the risk of deadlock which would happen otherwise.
Card detect workqueue is now disabled while userspace is frozen, Therefore
if you do use CONFIG_MMC_UNSAFE_RESUME, and remove the card during
suspend, the removal will be detected as soon as userspace is unfrozen,
again at the moment it is safe to call del_gendisk.
Tested with and without CONFIG_MMC_UNSAFE_RESUME with suspend and hibernate.
[akpm@linux-foundation.org: clean up function prototype]
[akpm@linux-foundation.org: fix CONFIG_PM-n linkage, small cleanups]
[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
Cc: David Brownell <david-b@pacbell.net>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-11 09:01:41 +08:00
|
|
|
mmc_detach_bus(host);
|
2011-09-22 02:08:13 +08:00
|
|
|
mmc_power_off(host);
|
mmc: fix all hangs related to mmc/sd card insert/removal during suspend/resume
If you don't use CONFIG_MMC_UNSAFE_RESUME, as soon as you attempt to
suspend, the card will be removed, therefore this patch doesn't change the
behavior of this option.
However the removal will be done by pm notifier, which runs while
userspace is still not frozen and thus can freely use del_gendisk, without
the risk of deadlock which would happen otherwise.
Card detect workqueue is now disabled while userspace is frozen, Therefore
if you do use CONFIG_MMC_UNSAFE_RESUME, and remove the card during
suspend, the removal will be detected as soon as userspace is unfrozen,
again at the moment it is safe to call del_gendisk.
Tested with and without CONFIG_MMC_UNSAFE_RESUME with suspend and hibernate.
[akpm@linux-foundation.org: clean up function prototype]
[akpm@linux-foundation.org: fix CONFIG_PM-n linkage, small cleanups]
[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
Cc: David Brownell <david-b@pacbell.net>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-11 09:01:41 +08:00
|
|
|
mmc_release_host(host);
|
|
|
|
host->pm_flags = 0;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case PM_POST_SUSPEND:
|
|
|
|
case PM_POST_HIBERNATION:
|
2010-12-10 15:40:31 +08:00
|
|
|
case PM_POST_RESTORE:
|
mmc: fix all hangs related to mmc/sd card insert/removal during suspend/resume
If you don't use CONFIG_MMC_UNSAFE_RESUME, as soon as you attempt to
suspend, the card will be removed, therefore this patch doesn't change the
behavior of this option.
However the removal will be done by pm notifier, which runs while
userspace is still not frozen and thus can freely use del_gendisk, without
the risk of deadlock which would happen otherwise.
Card detect workqueue is now disabled while userspace is frozen, Therefore
if you do use CONFIG_MMC_UNSAFE_RESUME, and remove the card during
suspend, the removal will be detected as soon as userspace is unfrozen,
again at the moment it is safe to call del_gendisk.
Tested with and without CONFIG_MMC_UNSAFE_RESUME with suspend and hibernate.
[akpm@linux-foundation.org: clean up function prototype]
[akpm@linux-foundation.org: fix CONFIG_PM-n linkage, small cleanups]
[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
Cc: David Brownell <david-b@pacbell.net>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-11 09:01:41 +08:00
|
|
|
|
|
|
|
spin_lock_irqsave(&host->lock, flags);
|
|
|
|
host->rescan_disable = 0;
|
|
|
|
spin_unlock_irqrestore(&host->lock, flags);
|
2013-09-20 17:02:35 +08:00
|
|
|
_mmc_detect_change(host, 0, false);
|
mmc: fix all hangs related to mmc/sd card insert/removal during suspend/resume
If you don't use CONFIG_MMC_UNSAFE_RESUME, as soon as you attempt to
suspend, the card will be removed, therefore this patch doesn't change the
behavior of this option.
However the removal will be done by pm notifier, which runs while
userspace is still not frozen and thus can freely use del_gendisk, without
the risk of deadlock which would happen otherwise.
Card detect workqueue is now disabled while userspace is frozen, Therefore
if you do use CONFIG_MMC_UNSAFE_RESUME, and remove the card during
suspend, the removal will be detected as soon as userspace is unfrozen,
again at the moment it is safe to call del_gendisk.
Tested with and without CONFIG_MMC_UNSAFE_RESUME with suspend and hibernate.
[akpm@linux-foundation.org: clean up function prototype]
[akpm@linux-foundation.org: fix CONFIG_PM-n linkage, small cleanups]
[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
Cc: David Brownell <david-b@pacbell.net>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-11 09:01:41 +08:00
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
2015-11-05 23:11:12 +08:00
|
|
|
|
|
|
|
void mmc_register_pm_notifier(struct mmc_host *host)
|
|
|
|
{
|
|
|
|
host->pm_notify.notifier_call = mmc_pm_notify;
|
|
|
|
register_pm_notifier(&host->pm_notify);
|
|
|
|
}
|
|
|
|
|
|
|
|
void mmc_unregister_pm_notifier(struct mmc_host *host)
|
|
|
|
{
|
|
|
|
unregister_pm_notifier(&host->pm_notify);
|
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
#endif
|
|
|
|
|
2007-05-19 20:32:22 +08:00
|
|
|
static int __init mmc_init(void)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
ret = mmc_register_bus();
|
2007-05-26 19:48:18 +08:00
|
|
|
if (ret)
|
mmc: core: Optimize boot time by detecting cards simultaneously
The mmc workqueue is an ordered workqueue, allowing only one work to
execute per given time. As this workqueue is used for card detection, the
conseqeunce is that cards will be detected one by one waiting for each
other.
Moreover, most of the time spent during card initialization is waiting for
the card's internal firmware to be ready. From a CPU perspective this
typically means waiting for a completion variable to be kicked via an
IRQ-handler or waiting for a sleep timer to finish.
This behaviour of detecting/initializing cards is sub-optimal, especially
for SOCs having several controllers/cards.
Let's convert to use the system_freezable_wq for the mmc detect works.
This enables several works to be executed simultaneously and thus also
cards to be detected like so.
Tests on UX500, which holds two eMMC cards and an SD-card (actually also
an SDIO card, currently not detected), shows a significant improved
behaviour due to this change.
Before this change, both the eMMC cards waited for the SD card to be
initialized as its detect work entered the workqueue first. In some cases,
depending on the characteristic of the SD-card, they got delayed 1-1.5 s.
Additionally for the second eMMC, it needed to wait for the first eMMC to
be initialized which added another 120-190 ms.
Converting to the system_freezable_wq, removed these delays and made both
the eMMC cards available far earlier in the boot sequence.
Selecting the system_freezable_wq, in favour of for example the system_wq,
is because we need card detection mechanism to be disabled once userspace
are frozen during system PM. Currently the mmc core deal with this via PM
notifiers, but following patches may utilize the behaviour of the
system_freezable_wq, to simplify the use of the PM notifiers.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Alan Cooper <alcooperx@gmail.com>
Tested-by: Shawn Lin <shawn.lin@rock-chips.com>
2015-12-01 17:35:29 +08:00
|
|
|
return ret;
|
2007-05-26 19:48:18 +08:00
|
|
|
|
|
|
|
ret = mmc_register_host_class();
|
|
|
|
if (ret)
|
|
|
|
goto unregister_bus;
|
|
|
|
|
|
|
|
ret = sdio_register_bus();
|
|
|
|
if (ret)
|
|
|
|
goto unregister_host_class;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
unregister_host_class:
|
|
|
|
mmc_unregister_host_class();
|
|
|
|
unregister_bus:
|
|
|
|
mmc_unregister_bus();
|
2007-05-19 20:32:22 +08:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void __exit mmc_exit(void)
|
|
|
|
{
|
2007-05-26 19:48:18 +08:00
|
|
|
sdio_unregister_bus();
|
2007-05-19 20:32:22 +08:00
|
|
|
mmc_unregister_host_class();
|
|
|
|
mmc_unregister_bus();
|
|
|
|
}
|
|
|
|
|
2007-06-16 14:07:53 +08:00
|
|
|
subsys_initcall(mmc_init);
|
2007-05-19 20:32:22 +08:00
|
|
|
module_exit(mmc_exit);
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
MODULE_LICENSE("GPL");
|