2006-12-24 21:46:55 +00:00
|
|
|
/*
|
|
|
|
* include/linux/mmc/sd.h
|
|
|
|
*
|
|
|
|
* Copyright (C) 2005-2007 Pierre Ossman, All Rights Reserved.
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
* it under the terms of the GNU General Public License as published by
|
|
|
|
* the Free Software Foundation; either version 2 of the License, or (at
|
|
|
|
* your option) any later version.
|
|
|
|
*/
|
|
|
|
|
2011-05-27 20:04:03 +00:00
|
|
|
#ifndef LINUX_MMC_SD_H
|
|
|
|
#define LINUX_MMC_SD_H
|
2006-12-24 21:46:55 +00:00
|
|
|
|
|
|
|
/* SD commands type argument response */
|
|
|
|
/* class 0 */
|
|
|
|
/* This is basically the same command as for MMC with some quirks. */
|
|
|
|
#define SD_SEND_RELATIVE_ADDR 3 /* bcr R6 */
|
|
|
|
#define SD_SEND_IF_COND 8 /* bcr [11:0] See below R7 */
|
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 06:48:57 +00:00
|
|
|
#define SD_SWITCH_VOLTAGE 11 /* ac R1 */
|
2006-12-24 21:46:55 +00:00
|
|
|
|
|
|
|
/* class 10 */
|
|
|
|
#define SD_SWITCH 6 /* adtc [31:0] See below R1 */
|
|
|
|
|
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-11 21:17:46 +00:00
|
|
|
/* class 5 */
|
|
|
|
#define SD_ERASE_WR_BLK_START 32 /* ac [31:0] data addr R1 */
|
|
|
|
#define SD_ERASE_WR_BLK_END 33 /* ac [31:0] data addr R1 */
|
|
|
|
|
2006-12-24 21:46:55 +00:00
|
|
|
/* Application commands */
|
|
|
|
#define SD_APP_SET_BUS_WIDTH 6 /* ac [1:0] bus width R1 */
|
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-11 21:17:46 +00:00
|
|
|
#define SD_APP_SD_STATUS 13 /* adtc R1 */
|
2006-12-24 21:46:55 +00:00
|
|
|
#define SD_APP_SEND_NUM_WR_BLKS 22 /* adtc R1 */
|
|
|
|
#define SD_APP_OP_COND 41 /* bcr [31:0] OCR R3 */
|
|
|
|
#define SD_APP_SEND_SCR 51 /* adtc R1 */
|
|
|
|
|
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 06:48:57 +00:00
|
|
|
/* OCR bit definitions */
|
|
|
|
#define SD_OCR_S18R (1 << 24) /* 1.8V switching request */
|
|
|
|
#define SD_ROCR_S18A SD_OCR_S18R /* 1.8V switching accepted by card */
|
|
|
|
#define SD_OCR_XPC (1 << 28) /* SDXC power control */
|
|
|
|
#define SD_OCR_CCS (1 << 30) /* Card Capacity Status */
|
|
|
|
|
2006-12-24 21:46:55 +00:00
|
|
|
/*
|
|
|
|
* SD_SWITCH argument format:
|
|
|
|
*
|
|
|
|
* [31] Check (0) or switch (1)
|
|
|
|
* [30:24] Reserved (0)
|
|
|
|
* [23:20] Function group 6
|
|
|
|
* [19:16] Function group 5
|
|
|
|
* [15:12] Function group 4
|
|
|
|
* [11:8] Function group 3
|
|
|
|
* [7:4] Function group 2
|
|
|
|
* [3:0] Function group 1
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* SD_SEND_IF_COND argument format:
|
|
|
|
*
|
|
|
|
* [31:12] Reserved (0)
|
|
|
|
* [11:8] Host Voltage Supply Flags
|
|
|
|
* [7:0] Check Pattern (0xAA)
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* SCR field definitions
|
|
|
|
*/
|
|
|
|
|
|
|
|
#define SCR_SPEC_VER_0 0 /* Implements system specification 1.0 - 1.01 */
|
|
|
|
#define SCR_SPEC_VER_1 1 /* Implements system specification 1.10 */
|
2011-05-23 20:06:38 +00:00
|
|
|
#define SCR_SPEC_VER_2 2 /* Implements system specification 2.00-3.0X */
|
2006-12-24 21:46:55 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* SD bus widths
|
|
|
|
*/
|
|
|
|
#define SD_BUS_WIDTH_1 0
|
|
|
|
#define SD_BUS_WIDTH_4 2
|
|
|
|
|
|
|
|
/*
|
|
|
|
* SD_SWITCH mode
|
|
|
|
*/
|
|
|
|
#define SD_SWITCH_CHECK 0
|
|
|
|
#define SD_SWITCH_SET 1
|
|
|
|
|
|
|
|
/*
|
|
|
|
* SD_SWITCH function groups
|
|
|
|
*/
|
|
|
|
#define SD_SWITCH_GRP_ACCESS 0
|
|
|
|
|
|
|
|
/*
|
|
|
|
* SD_SWITCH access modes
|
|
|
|
*/
|
|
|
|
#define SD_SWITCH_ACCESS_DEF 0
|
|
|
|
#define SD_SWITCH_ACCESS_HS 1
|
|
|
|
|
2011-05-27 20:04:03 +00:00
|
|
|
#endif /* LINUX_MMC_SD_H */
|