2019-05-27 14:55:01 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-or-later
|
2006-12-25 05:46:55 +08:00
|
|
|
/*
|
2007-07-12 02:04:50 +08:00
|
|
|
* linux/drivers/mmc/core/sd_ops.h
|
2006-12-25 05:46:55 +08:00
|
|
|
*
|
|
|
|
* Copyright 2006-2007 Pierre Ossman
|
|
|
|
*/
|
|
|
|
|
2011-03-25 14:06:19 +08:00
|
|
|
#include <linux/slab.h>
|
2006-12-25 05:46:55 +08:00
|
|
|
#include <linux/types.h>
|
2011-07-11 00:42:00 +08:00
|
|
|
#include <linux/export.h>
|
2006-12-25 05:46:55 +08:00
|
|
|
#include <linux/scatterlist.h>
|
|
|
|
|
|
|
|
#include <linux/mmc/host.h>
|
|
|
|
#include <linux/mmc/card.h>
|
|
|
|
#include <linux/mmc/mmc.h>
|
|
|
|
#include <linux/mmc/sd.h>
|
|
|
|
|
|
|
|
#include "core.h"
|
|
|
|
#include "sd_ops.h"
|
|
|
|
|
2011-04-27 06:56:29 +08:00
|
|
|
int mmc_app_cmd(struct mmc_host *host, struct mmc_card *card)
|
2007-07-25 06:40:58 +08:00
|
|
|
{
|
|
|
|
int err;
|
2016-12-19 19:51:18 +08:00
|
|
|
struct mmc_command cmd = {};
|
2007-07-25 06:40:58 +08:00
|
|
|
|
2016-11-02 15:25:48 +08:00
|
|
|
if (WARN_ON(card && card->host != host))
|
|
|
|
return -EINVAL;
|
2007-07-25 06:40:58 +08:00
|
|
|
|
|
|
|
cmd.opcode = MMC_APP_CMD;
|
|
|
|
|
|
|
|
if (card) {
|
|
|
|
cmd.arg = card->rca << 16;
|
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
|
|
|
cmd.flags = MMC_RSP_SPI_R1 | MMC_RSP_R1 | MMC_CMD_AC;
|
2007-07-25 06:40:58 +08:00
|
|
|
} else {
|
|
|
|
cmd.arg = 0;
|
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
|
|
|
cmd.flags = MMC_RSP_SPI_R1 | MMC_RSP_R1 | MMC_CMD_BCR;
|
2007-07-25 06:40:58 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
err = mmc_wait_for_cmd(host, &cmd, 0);
|
2007-07-23 04:18:46 +08:00
|
|
|
if (err)
|
2007-07-25 06:40:58 +08:00
|
|
|
return err;
|
|
|
|
|
|
|
|
/* Check that card supported application commands */
|
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 (!mmc_host_is_spi(host) && !(cmd.resp[0] & R1_APP_CMD))
|
2007-07-23 04:18:46 +08:00
|
|
|
return -EOPNOTSUPP;
|
2007-07-25 06:40:58 +08:00
|
|
|
|
2007-07-23 04:18:46 +08:00
|
|
|
return 0;
|
2007-07-25 06:40:58 +08:00
|
|
|
}
|
2011-04-27 06:56:29 +08:00
|
|
|
EXPORT_SYMBOL_GPL(mmc_app_cmd);
|
2007-07-25 06:40:58 +08:00
|
|
|
|
2019-02-13 21:49:15 +08:00
|
|
|
static int mmc_wait_for_app_cmd(struct mmc_host *host, struct mmc_card *card,
|
2019-02-13 22:17:13 +08:00
|
|
|
struct mmc_command *cmd)
|
2006-12-25 05:46:55 +08:00
|
|
|
{
|
2016-12-19 19:51:18 +08:00
|
|
|
struct mmc_request mrq = {};
|
2019-02-13 22:17:13 +08:00
|
|
|
int i, err = -EIO;
|
2006-12-25 05:46:55 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* We have to resend MMC_APP_CMD for each attempt so
|
|
|
|
* we cannot use the retries field in mmc_command.
|
|
|
|
*/
|
2019-02-13 22:17:13 +08:00
|
|
|
for (i = 0; i <= MMC_CMD_RETRIES; i++) {
|
2006-12-25 05:46:55 +08:00
|
|
|
err = mmc_app_cmd(host, card);
|
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) {
|
|
|
|
/* no point in retrying; no APP commands allowed */
|
|
|
|
if (mmc_host_is_spi(host)) {
|
|
|
|
if (cmd->resp[0] & R1_SPI_ILLEGAL_COMMAND)
|
|
|
|
break;
|
|
|
|
}
|
2006-12-25 05:46:55 +08:00
|
|
|
continue;
|
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
|
|
|
}
|
2006-12-25 05:46:55 +08:00
|
|
|
|
|
|
|
memset(&mrq, 0, sizeof(struct mmc_request));
|
|
|
|
|
|
|
|
memset(cmd->resp, 0, sizeof(cmd->resp));
|
|
|
|
cmd->retries = 0;
|
|
|
|
|
|
|
|
mrq.cmd = cmd;
|
|
|
|
cmd->data = NULL;
|
|
|
|
|
|
|
|
mmc_wait_for_req(host, &mrq);
|
|
|
|
|
|
|
|
err = cmd->error;
|
2007-07-23 04:18:46 +08:00
|
|
|
if (!cmd->error)
|
2006-12-25 05:46:55 +08:00
|
|
|
break;
|
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
|
|
|
|
|
|
|
/* no point in retrying illegal APP commands */
|
|
|
|
if (mmc_host_is_spi(host)) {
|
|
|
|
if (cmd->resp[0] & R1_SPI_ILLEGAL_COMMAND)
|
|
|
|
break;
|
|
|
|
}
|
2006-12-25 05:46:55 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
int mmc_app_set_bus_width(struct mmc_card *card, int width)
|
|
|
|
{
|
2016-12-19 19:51:18 +08:00
|
|
|
struct mmc_command cmd = {};
|
2006-12-25 05:46:55 +08:00
|
|
|
|
|
|
|
cmd.opcode = SD_APP_SET_BUS_WIDTH;
|
|
|
|
cmd.flags = MMC_RSP_R1 | MMC_CMD_AC;
|
|
|
|
|
|
|
|
switch (width) {
|
|
|
|
case MMC_BUS_WIDTH_1:
|
|
|
|
cmd.arg = SD_BUS_WIDTH_1;
|
|
|
|
break;
|
|
|
|
case MMC_BUS_WIDTH_4:
|
|
|
|
cmd.arg = SD_BUS_WIDTH_4;
|
|
|
|
break;
|
|
|
|
default:
|
2007-07-23 04:18:46 +08:00
|
|
|
return -EINVAL;
|
2006-12-25 05:46:55 +08:00
|
|
|
}
|
|
|
|
|
2019-02-13 22:17:13 +08:00
|
|
|
return mmc_wait_for_app_cmd(card->host, card, &cmd);
|
2006-12-25 05:46:55 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
int mmc_send_app_op_cond(struct mmc_host *host, u32 ocr, u32 *rocr)
|
|
|
|
{
|
2016-12-19 19:51:18 +08:00
|
|
|
struct mmc_command cmd = {};
|
2006-12-25 05:46:55 +08:00
|
|
|
int i, err = 0;
|
|
|
|
|
|
|
|
cmd.opcode = SD_APP_OP_COND;
|
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 (mmc_host_is_spi(host))
|
|
|
|
cmd.arg = ocr & (1 << 30); /* SPI only defines one bit */
|
|
|
|
else
|
|
|
|
cmd.arg = ocr;
|
|
|
|
cmd.flags = MMC_RSP_SPI_R1 | MMC_RSP_R3 | MMC_CMD_BCR;
|
2006-12-25 05:46:55 +08:00
|
|
|
|
|
|
|
for (i = 100; i; i--) {
|
2019-02-13 22:17:13 +08:00
|
|
|
err = mmc_wait_for_app_cmd(host, NULL, &cmd);
|
2007-07-23 04:18:46 +08:00
|
|
|
if (err)
|
2006-12-25 05:46:55 +08:00
|
|
|
break;
|
|
|
|
|
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 we're just probing, do a single pass */
|
|
|
|
if (ocr == 0)
|
2006-12-25 05:46:55 +08:00
|
|
|
break;
|
|
|
|
|
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
|
|
|
/* otherwise wait until reset completes */
|
|
|
|
if (mmc_host_is_spi(host)) {
|
|
|
|
if (!(cmd.resp[0] & R1_SPI_IDLE))
|
|
|
|
break;
|
|
|
|
} else {
|
|
|
|
if (cmd.resp[0] & MMC_CARD_BUSY)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2007-07-23 04:18:46 +08:00
|
|
|
err = -ETIMEDOUT;
|
2006-12-25 05:46:55 +08:00
|
|
|
|
|
|
|
mmc_delay(10);
|
|
|
|
}
|
|
|
|
|
2014-05-23 22:15:03 +08:00
|
|
|
if (!i)
|
|
|
|
pr_err("%s: card never left busy state\n", mmc_hostname(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 (rocr && !mmc_host_is_spi(host))
|
2006-12-25 05:46:55 +08:00
|
|
|
*rocr = cmd.resp[0];
|
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
mmc: core: Initial support for SD express card/host
In the SD specification v7.10 the SD express card has been added. This new
type of removable SD card, can be managed via a PCIe/NVMe based interface,
while also allowing backwards compatibility towards the legacy SD
interface.
To keep the backwards compatibility, it's required to start the
initialization through the legacy SD interface. If it turns out that the
mmc host and the SD card, both supports the PCIe/NVMe interface, then a
switch should be allowed.
Therefore, let's introduce some basic support for this type of SD cards to
the mmc core. The mmc host, should set MMC_CAP2_SD_EXP if it supports this
interface and MMC_CAP2_SD_EXP_1_2V, if also 1.2V is supported, as to inform
the core about it.
To deal with the switch to the PCIe/NVMe interface, the mmc host is
required to implement a new host ops, ->init_sd_express(). Based on the
initial communication between the host and the card, host->ios.timing is
set to either MMC_TIMING_SD_EXP or MMC_TIMING_SD_EXP_1_2V, depending on if
1.2V is supported or not. In this way, the mmc host can check these values
in its ->init_sd_express() ops, to know how to proceed with the handover.
Note that, to manage card insert/removal, the mmc core sticks with using
the ->get_cd() callback, which means it's the host's responsibility to make
sure it provides valid data, even if the card may be managed by PCIe/NVMe
at the moment. As long as the card seems to be present, the mmc core keeps
the card powered on.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Rui Feng <rui_feng@realsil.com.cn>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/1603936636-3126-1-git-send-email-rui_feng@realsil.com.cn
2020-10-29 09:57:16 +08:00
|
|
|
static int __mmc_send_if_cond(struct mmc_host *host, u32 ocr, u8 pcie_bits,
|
|
|
|
u32 *resp)
|
2006-12-25 05:46:55 +08:00
|
|
|
{
|
2016-12-19 19:51:18 +08:00
|
|
|
struct mmc_command cmd = {};
|
2006-12-25 05:46:55 +08:00
|
|
|
int err;
|
|
|
|
static const u8 test_pattern = 0xAA;
|
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
|
|
|
u8 result_pattern;
|
2006-12-25 05:46:55 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* To support SD 2.0 cards, we must always invoke SD_SEND_IF_COND
|
|
|
|
* before SD_APP_OP_COND. This command will harmlessly fail for
|
|
|
|
* SD 1.0 cards.
|
|
|
|
*/
|
|
|
|
cmd.opcode = SD_SEND_IF_COND;
|
mmc: core: Initial support for SD express card/host
In the SD specification v7.10 the SD express card has been added. This new
type of removable SD card, can be managed via a PCIe/NVMe based interface,
while also allowing backwards compatibility towards the legacy SD
interface.
To keep the backwards compatibility, it's required to start the
initialization through the legacy SD interface. If it turns out that the
mmc host and the SD card, both supports the PCIe/NVMe interface, then a
switch should be allowed.
Therefore, let's introduce some basic support for this type of SD cards to
the mmc core. The mmc host, should set MMC_CAP2_SD_EXP if it supports this
interface and MMC_CAP2_SD_EXP_1_2V, if also 1.2V is supported, as to inform
the core about it.
To deal with the switch to the PCIe/NVMe interface, the mmc host is
required to implement a new host ops, ->init_sd_express(). Based on the
initial communication between the host and the card, host->ios.timing is
set to either MMC_TIMING_SD_EXP or MMC_TIMING_SD_EXP_1_2V, depending on if
1.2V is supported or not. In this way, the mmc host can check these values
in its ->init_sd_express() ops, to know how to proceed with the handover.
Note that, to manage card insert/removal, the mmc core sticks with using
the ->get_cd() callback, which means it's the host's responsibility to make
sure it provides valid data, even if the card may be managed by PCIe/NVMe
at the moment. As long as the card seems to be present, the mmc core keeps
the card powered on.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Rui Feng <rui_feng@realsil.com.cn>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/1603936636-3126-1-git-send-email-rui_feng@realsil.com.cn
2020-10-29 09:57:16 +08:00
|
|
|
cmd.arg = ((ocr & 0xFF8000) != 0) << 8 | pcie_bits << 8 | test_pattern;
|
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
|
|
|
cmd.flags = MMC_RSP_SPI_R7 | MMC_RSP_R7 | MMC_CMD_BCR;
|
2006-12-25 05:46:55 +08:00
|
|
|
|
|
|
|
err = mmc_wait_for_cmd(host, &cmd, 0);
|
2007-07-23 04:18:46 +08:00
|
|
|
if (err)
|
2006-12-25 05:46:55 +08:00
|
|
|
return err;
|
|
|
|
|
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 (mmc_host_is_spi(host))
|
|
|
|
result_pattern = cmd.resp[1] & 0xFF;
|
|
|
|
else
|
|
|
|
result_pattern = cmd.resp[0] & 0xFF;
|
|
|
|
|
|
|
|
if (result_pattern != test_pattern)
|
2007-07-23 04:18:46 +08:00
|
|
|
return -EIO;
|
2006-12-25 05:46:55 +08:00
|
|
|
|
mmc: core: Initial support for SD express card/host
In the SD specification v7.10 the SD express card has been added. This new
type of removable SD card, can be managed via a PCIe/NVMe based interface,
while also allowing backwards compatibility towards the legacy SD
interface.
To keep the backwards compatibility, it's required to start the
initialization through the legacy SD interface. If it turns out that the
mmc host and the SD card, both supports the PCIe/NVMe interface, then a
switch should be allowed.
Therefore, let's introduce some basic support for this type of SD cards to
the mmc core. The mmc host, should set MMC_CAP2_SD_EXP if it supports this
interface and MMC_CAP2_SD_EXP_1_2V, if also 1.2V is supported, as to inform
the core about it.
To deal with the switch to the PCIe/NVMe interface, the mmc host is
required to implement a new host ops, ->init_sd_express(). Based on the
initial communication between the host and the card, host->ios.timing is
set to either MMC_TIMING_SD_EXP or MMC_TIMING_SD_EXP_1_2V, depending on if
1.2V is supported or not. In this way, the mmc host can check these values
in its ->init_sd_express() ops, to know how to proceed with the handover.
Note that, to manage card insert/removal, the mmc core sticks with using
the ->get_cd() callback, which means it's the host's responsibility to make
sure it provides valid data, even if the card may be managed by PCIe/NVMe
at the moment. As long as the card seems to be present, the mmc core keeps
the card powered on.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Rui Feng <rui_feng@realsil.com.cn>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/1603936636-3126-1-git-send-email-rui_feng@realsil.com.cn
2020-10-29 09:57:16 +08:00
|
|
|
if (resp)
|
|
|
|
*resp = cmd.resp[0];
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
int mmc_send_if_cond(struct mmc_host *host, u32 ocr)
|
|
|
|
{
|
|
|
|
return __mmc_send_if_cond(host, ocr, 0, NULL);
|
|
|
|
}
|
|
|
|
|
|
|
|
int mmc_send_if_cond_pcie(struct mmc_host *host, u32 ocr)
|
|
|
|
{
|
|
|
|
u32 resp = 0;
|
|
|
|
u8 pcie_bits = 0;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (host->caps2 & MMC_CAP2_SD_EXP) {
|
|
|
|
/* Probe card for SD express support via PCIe. */
|
|
|
|
pcie_bits = 0x10;
|
|
|
|
if (host->caps2 & MMC_CAP2_SD_EXP_1_2V)
|
|
|
|
/* Probe also for 1.2V support. */
|
|
|
|
pcie_bits = 0x30;
|
|
|
|
}
|
|
|
|
|
|
|
|
ret = __mmc_send_if_cond(host, ocr, pcie_bits, &resp);
|
|
|
|
if (ret)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/* Continue with the SD express init, if the card supports it. */
|
|
|
|
resp &= 0x3000;
|
|
|
|
if (pcie_bits && resp) {
|
|
|
|
if (resp == 0x3000)
|
|
|
|
host->ios.timing = MMC_TIMING_SD_EXP_1_2V;
|
|
|
|
else
|
|
|
|
host->ios.timing = MMC_TIMING_SD_EXP;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* According to the spec the clock shall also be gated, but
|
|
|
|
* let's leave this to the host driver for more flexibility.
|
|
|
|
*/
|
|
|
|
return host->ops->init_sd_express(host, &host->ios);
|
|
|
|
}
|
|
|
|
|
2007-07-23 04:18:46 +08:00
|
|
|
return 0;
|
2006-12-25 05:46:55 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
int mmc_send_relative_addr(struct mmc_host *host, unsigned int *rca)
|
|
|
|
{
|
|
|
|
int err;
|
2016-12-19 19:51:18 +08:00
|
|
|
struct mmc_command cmd = {};
|
2006-12-25 05:46:55 +08:00
|
|
|
|
|
|
|
cmd.opcode = SD_SEND_RELATIVE_ADDR;
|
|
|
|
cmd.arg = 0;
|
|
|
|
cmd.flags = MMC_RSP_R6 | MMC_CMD_BCR;
|
|
|
|
|
|
|
|
err = mmc_wait_for_cmd(host, &cmd, MMC_CMD_RETRIES);
|
2007-07-23 04:18:46 +08:00
|
|
|
if (err)
|
2006-12-25 05:46:55 +08:00
|
|
|
return err;
|
|
|
|
|
|
|
|
*rca = cmd.resp[0] >> 16;
|
|
|
|
|
2007-07-23 04:18:46 +08:00
|
|
|
return 0;
|
2006-12-25 05:46:55 +08:00
|
|
|
}
|
|
|
|
|
2017-04-03 04:56:03 +08:00
|
|
|
int mmc_app_send_scr(struct mmc_card *card)
|
2006-12-25 05:46:55 +08:00
|
|
|
{
|
|
|
|
int err;
|
2016-12-19 19:51:18 +08:00
|
|
|
struct mmc_request mrq = {};
|
|
|
|
struct mmc_command cmd = {};
|
|
|
|
struct mmc_data data = {};
|
2006-12-25 05:46:55 +08:00
|
|
|
struct scatterlist sg;
|
2017-04-03 04:56:03 +08:00
|
|
|
__be32 *scr;
|
2006-12-25 05:46:55 +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
|
|
|
/* NOTE: caller guarantees scr is heap-allocated */
|
|
|
|
|
2006-12-25 05:46:55 +08:00
|
|
|
err = mmc_app_cmd(card->host, card);
|
2007-07-23 04:18:46 +08:00
|
|
|
if (err)
|
2006-12-25 05:46:55 +08:00
|
|
|
return err;
|
|
|
|
|
2011-03-25 14:06:19 +08:00
|
|
|
/* dma onto stack is unsafe/nonportable, but callers to this
|
|
|
|
* routine normally provide temporary on-stack buffers ...
|
|
|
|
*/
|
2017-04-03 04:56:03 +08:00
|
|
|
scr = kmalloc(sizeof(card->raw_scr), GFP_KERNEL);
|
|
|
|
if (!scr)
|
2011-03-25 14:06:19 +08:00
|
|
|
return -ENOMEM;
|
|
|
|
|
2006-12-25 05:46:55 +08:00
|
|
|
mrq.cmd = &cmd;
|
|
|
|
mrq.data = &data;
|
|
|
|
|
|
|
|
cmd.opcode = SD_APP_SEND_SCR;
|
|
|
|
cmd.arg = 0;
|
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
|
|
|
cmd.flags = MMC_RSP_SPI_R1 | MMC_RSP_R1 | MMC_CMD_ADTC;
|
2006-12-25 05:46:55 +08:00
|
|
|
|
|
|
|
data.blksz = 8;
|
|
|
|
data.blocks = 1;
|
|
|
|
data.flags = MMC_DATA_READ;
|
|
|
|
data.sg = &sg;
|
|
|
|
data.sg_len = 1;
|
|
|
|
|
2017-04-03 04:56:03 +08:00
|
|
|
sg_init_one(&sg, scr, 8);
|
2006-12-25 05:46:55 +08:00
|
|
|
|
2007-07-25 01:16:54 +08:00
|
|
|
mmc_set_data_timeout(&data, card);
|
2006-12-25 05:46:55 +08:00
|
|
|
|
|
|
|
mmc_wait_for_req(card->host, &mrq);
|
|
|
|
|
2017-04-03 04:56:03 +08:00
|
|
|
card->raw_scr[0] = be32_to_cpu(scr[0]);
|
|
|
|
card->raw_scr[1] = be32_to_cpu(scr[1]);
|
|
|
|
|
|
|
|
kfree(scr);
|
2011-03-25 14:06:19 +08:00
|
|
|
|
2007-07-23 04:18:46 +08:00
|
|
|
if (cmd.error)
|
2006-12-25 05:46:55 +08:00
|
|
|
return cmd.error;
|
2007-07-23 04:18:46 +08:00
|
|
|
if (data.error)
|
2006-12-25 05:46:55 +08:00
|
|
|
return data.error;
|
|
|
|
|
2007-07-23 04:18:46 +08:00
|
|
|
return 0;
|
2006-12-25 05:46:55 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
int mmc_sd_switch(struct mmc_card *card, int mode, int group,
|
|
|
|
u8 value, u8 *resp)
|
|
|
|
{
|
2016-12-19 19:51:18 +08:00
|
|
|
struct mmc_request mrq = {};
|
|
|
|
struct mmc_command cmd = {};
|
|
|
|
struct mmc_data data = {};
|
2006-12-25 05:46:55 +08:00
|
|
|
struct scatterlist sg;
|
|
|
|
|
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
|
|
|
/* NOTE: caller guarantees resp is heap-allocated */
|
|
|
|
|
2006-12-25 05:46:55 +08:00
|
|
|
mode = !!mode;
|
|
|
|
value &= 0xF;
|
|
|
|
|
|
|
|
mrq.cmd = &cmd;
|
|
|
|
mrq.data = &data;
|
|
|
|
|
|
|
|
cmd.opcode = SD_SWITCH;
|
|
|
|
cmd.arg = mode << 31 | 0x00FFFFFF;
|
|
|
|
cmd.arg &= ~(0xF << (group * 4));
|
|
|
|
cmd.arg |= value << (group * 4);
|
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
|
|
|
cmd.flags = MMC_RSP_SPI_R1 | MMC_RSP_R1 | MMC_CMD_ADTC;
|
2006-12-25 05:46:55 +08:00
|
|
|
|
|
|
|
data.blksz = 64;
|
|
|
|
data.blocks = 1;
|
|
|
|
data.flags = MMC_DATA_READ;
|
|
|
|
data.sg = &sg;
|
|
|
|
data.sg_len = 1;
|
|
|
|
|
|
|
|
sg_init_one(&sg, resp, 64);
|
|
|
|
|
2007-07-25 01:16:54 +08:00
|
|
|
mmc_set_data_timeout(&data, card);
|
2006-12-25 05:46:55 +08:00
|
|
|
|
|
|
|
mmc_wait_for_req(card->host, &mrq);
|
|
|
|
|
2007-07-23 04:18:46 +08:00
|
|
|
if (cmd.error)
|
2006-12-25 05:46:55 +08:00
|
|
|
return cmd.error;
|
2007-07-23 04:18:46 +08:00
|
|
|
if (data.error)
|
2006-12-25 05:46:55 +08:00
|
|
|
return data.error;
|
|
|
|
|
2007-07-23 04:18:46 +08:00
|
|
|
return 0;
|
2006-12-25 05:46:55 +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
|
|
|
int mmc_app_sd_status(struct mmc_card *card, void *ssr)
|
|
|
|
{
|
|
|
|
int err;
|
2016-12-19 19:51:18 +08:00
|
|
|
struct mmc_request mrq = {};
|
|
|
|
struct mmc_command cmd = {};
|
|
|
|
struct mmc_data data = {};
|
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
|
|
|
struct scatterlist sg;
|
|
|
|
|
|
|
|
/* NOTE: caller guarantees ssr is heap-allocated */
|
|
|
|
|
|
|
|
err = mmc_app_cmd(card->host, card);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
|
|
|
mrq.cmd = &cmd;
|
|
|
|
mrq.data = &data;
|
|
|
|
|
|
|
|
cmd.opcode = SD_APP_SD_STATUS;
|
|
|
|
cmd.arg = 0;
|
|
|
|
cmd.flags = MMC_RSP_SPI_R2 | MMC_RSP_R1 | MMC_CMD_ADTC;
|
|
|
|
|
|
|
|
data.blksz = 64;
|
|
|
|
data.blocks = 1;
|
|
|
|
data.flags = MMC_DATA_READ;
|
|
|
|
data.sg = &sg;
|
|
|
|
data.sg_len = 1;
|
|
|
|
|
|
|
|
sg_init_one(&sg, ssr, 64);
|
|
|
|
|
|
|
|
mmc_set_data_timeout(&data, card);
|
|
|
|
|
|
|
|
mmc_wait_for_req(card->host, &mrq);
|
|
|
|
|
|
|
|
if (cmd.error)
|
|
|
|
return cmd.error;
|
|
|
|
if (data.error)
|
|
|
|
return data.error;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|