2008-10-21 20:33:40 +00:00
|
|
|
/*-
|
2017-11-27 14:52:40 +00:00
|
|
|
* SPDX-License-Identifier: BSD-2-Clause-FreeBSD
|
|
|
|
|
*
|
2008-10-21 20:33:40 +00:00
|
|
|
* Copyright (c) 2008 Alexander Motin <mav@FreeBSD.org>
|
|
|
|
|
* All rights reserved.
|
|
|
|
|
*
|
|
|
|
|
* Redistribution and use in source and binary forms, with or without
|
|
|
|
|
* modification, are permitted provided that the following conditions
|
|
|
|
|
* are met:
|
|
|
|
|
* 1. Redistributions of source code must retain the above copyright
|
|
|
|
|
* notice, this list of conditions and the following disclaimer.
|
|
|
|
|
* 2. Redistributions in binary form must reproduce the above copyright
|
|
|
|
|
* notice, this list of conditions and the following disclaimer in the
|
|
|
|
|
* documentation and/or other materials provided with the distribution.
|
|
|
|
|
*
|
|
|
|
|
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
|
|
|
|
|
* IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
|
|
|
|
|
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
|
|
|
|
|
* IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
|
|
|
|
|
* INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
|
|
|
|
|
* NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
|
|
|
|
|
* DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
|
|
|
|
|
* THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
|
|
|
|
|
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
|
|
|
|
|
* THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
|
|
|
|
*
|
|
|
|
|
* $FreeBSD$
|
|
|
|
|
*/
|
|
|
|
|
|
2012-10-16 01:10:43 +00:00
|
|
|
#ifndef __SDHCI_H__
|
|
|
|
|
#define __SDHCI_H__
|
2008-10-21 20:33:40 +00:00
|
|
|
|
2017-07-10 03:38:17 +00:00
|
|
|
#include "opt_mmccam.h"
|
|
|
|
|
|
2017-02-04 19:35:38 +00:00
|
|
|
#define DMA_BLOCK_SIZE 4096
|
|
|
|
|
#define DMA_BOUNDARY 0 /* DMA reload every 4K */
|
2008-10-21 20:33:40 +00:00
|
|
|
|
2012-10-16 01:10:43 +00:00
|
|
|
/* Controller doesn't honor resets unless we touch the clock register */
|
2017-02-04 19:35:38 +00:00
|
|
|
#define SDHCI_QUIRK_CLOCK_BEFORE_RESET (1 << 0)
|
2012-10-16 01:10:43 +00:00
|
|
|
/* Controller really supports DMA */
|
2017-02-04 19:35:38 +00:00
|
|
|
#define SDHCI_QUIRK_FORCE_DMA (1 << 1)
|
2012-10-16 01:10:43 +00:00
|
|
|
/* Controller has unusable DMA engine */
|
2017-02-04 19:35:38 +00:00
|
|
|
#define SDHCI_QUIRK_BROKEN_DMA (1 << 2)
|
2012-10-16 01:10:43 +00:00
|
|
|
/* Controller doesn't like to be reset when there is no card inserted. */
|
2017-02-04 19:35:38 +00:00
|
|
|
#define SDHCI_QUIRK_NO_CARD_NO_RESET (1 << 3)
|
2012-10-16 01:10:43 +00:00
|
|
|
/* Controller has flaky internal state so reset it on each ios change */
|
2017-02-04 19:35:38 +00:00
|
|
|
#define SDHCI_QUIRK_RESET_ON_IOS (1 << 4)
|
2012-10-16 01:10:43 +00:00
|
|
|
/* Controller can only DMA chunk sizes that are a multiple of 32 bits */
|
2017-02-04 19:35:38 +00:00
|
|
|
#define SDHCI_QUIRK_32BIT_DMA_SIZE (1 << 5)
|
2012-10-16 01:10:43 +00:00
|
|
|
/* Controller needs to be reset after each request to stay stable */
|
2017-02-04 19:35:38 +00:00
|
|
|
#define SDHCI_QUIRK_RESET_AFTER_REQUEST (1 << 6)
|
2012-10-16 01:10:43 +00:00
|
|
|
/* Controller has an off-by-one issue with timeout value */
|
2017-02-04 19:35:38 +00:00
|
|
|
#define SDHCI_QUIRK_INCR_TIMEOUT_CONTROL (1 << 7)
|
2012-10-16 01:10:43 +00:00
|
|
|
/* Controller has broken read timings */
|
2017-02-04 19:35:38 +00:00
|
|
|
#define SDHCI_QUIRK_BROKEN_TIMINGS (1 << 8)
|
2012-10-16 01:10:43 +00:00
|
|
|
/* Controller needs lowered frequency */
|
2017-02-04 19:35:38 +00:00
|
|
|
#define SDHCI_QUIRK_LOWER_FREQUENCY (1 << 9)
|
2012-10-29 17:21:58 +00:00
|
|
|
/* Data timeout is invalid, should use SD clock */
|
2017-02-04 19:35:38 +00:00
|
|
|
#define SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK (1 << 10)
|
2012-10-29 17:21:58 +00:00
|
|
|
/* Timeout value is invalid, should be overriden */
|
2017-02-04 19:35:38 +00:00
|
|
|
#define SDHCI_QUIRK_BROKEN_TIMEOUT_VAL (1 << 11)
|
2012-10-29 17:21:58 +00:00
|
|
|
/* SDHCI_CAPABILITIES is invalid */
|
2017-02-04 19:35:38 +00:00
|
|
|
#define SDHCI_QUIRK_MISSING_CAPS (1 << 12)
|
2013-08-18 19:08:53 +00:00
|
|
|
/* Hardware shifts the 136-bit response, don't do it in software. */
|
2017-02-04 19:35:38 +00:00
|
|
|
#define SDHCI_QUIRK_DONT_SHIFT_RESPONSE (1 << 13)
|
2014-12-20 01:13:13 +00:00
|
|
|
/* Wait to see reset bit asserted before waiting for de-asserted */
|
2017-02-04 19:35:38 +00:00
|
|
|
#define SDHCI_QUIRK_WAITFOR_RESET_ASSERTED (1 << 14)
|
2015-01-17 19:57:03 +00:00
|
|
|
/* Leave controller in standard mode when putting card in HS mode. */
|
2017-02-04 19:35:38 +00:00
|
|
|
#define SDHCI_QUIRK_DONT_SET_HISPD_BIT (1 << 15)
|
2015-10-15 04:22:56 +00:00
|
|
|
/* Alternate clock source is required when supplying a 400 KHz clock. */
|
2017-02-04 19:35:38 +00:00
|
|
|
#define SDHCI_QUIRK_BCM577XX_400KHZ_CLKSRC (1 << 16)
|
2017-01-09 01:15:18 +00:00
|
|
|
/* Card insert/remove interrupts don't work, polling required. */
|
2017-02-04 19:35:38 +00:00
|
|
|
#define SDHCI_QUIRK_POLL_CARD_PRESENT (1 << 17)
|
2017-01-09 17:07:13 +00:00
|
|
|
/* All controller slots are non-removable. */
|
2017-02-04 19:35:38 +00:00
|
|
|
#define SDHCI_QUIRK_ALL_SLOTS_NON_REMOVABLE (1 << 18)
|
2017-01-09 17:07:13 +00:00
|
|
|
/* Issue custom Intel controller reset sequence after power-up. */
|
2017-02-04 19:35:38 +00:00
|
|
|
#define SDHCI_QUIRK_INTEL_POWER_UP_RESET (1 << 19)
|
2017-01-09 17:07:13 +00:00
|
|
|
/* Data timeout is invalid, use 1 MHz clock instead. */
|
2017-02-04 19:35:38 +00:00
|
|
|
#define SDHCI_QUIRK_DATA_TIMEOUT_1MHZ (1 << 20)
|
- Add support for eMMC "partitions". Besides the user data area, i. e.
the default partition, eMMC v4.41 and later devices can additionally
provide up to:
1 enhanced user data area partition
2 boot partitions
1 RPMB (Replay Protected Memory Block) partition
4 general purpose partitions (optionally with a enhanced or extended
attribute)
Of these "partitions", only the enhanced user data area one actually
slices the user data area partition and, thus, gets handled with the
help of geom_flashmap(4). The other types of partitions have address
space independent from the default partition and need to be switched
to via CMD6 (SWITCH), i. e. constitute a set of additional "disks".
The second kind of these "partitions" doesn't fit that well into the
design of mmc(4) and mmcsd(4). I've decided to let mmcsd(4) hook all
of these "partitions" up as disk(9)'s (except for the RPMB partition
as it didn't seem to make much sense to be able to put a file-system
there and may require authentication; therefore, RPMB partitions are
solely accessible via the newly added IOCTL interface currently; see
also below). This approach for one resulted in cleaner code. Second,
it retains the notion of mmcsd(4) children corresponding to a single
physical device each. With the addition of some layering violations,
it also would have been possible for mmc(4) to add separate mmcsd(4)
instances with one disk each for all of these "partitions", however.
Still, both mmc(4) and mmcsd(4) share some common code now e. g. for
issuing CMD6, which has been factored out into mmc_subr.c.
Besides simply subdividing eMMC devices, some Intel NUCs having UEFI
code in the boot partitions etc., another use case for the partition
support is the activation of pseudo-SLC mode, which manufacturers of
eMMC chips typically associate with the enhanced user data area and/
or the enhanced attribute of general purpose partitions.
CAVEAT EMPTOR: Partitioning eMMC devices is a one-time operation.
- Now that properly issuing CMD6 is crucial (so data isn't written to
the wrong partition for example), make a step into the direction of
correctly handling the timeout for these commands in the MMC layer.
Also, do a SEND_STATUS when CMD6 is invoked with an R1B response as
recommended by relevant specifications. However, quite some work is
left to be done in this regard; all other R1B-type commands done by
the MMC layer also should be followed by a SEND_STATUS (CMD13), the
erase timeout calculations/handling as documented in specifications
are entirely ignored so far, the MMC layer doesn't provide timeouts
applicable up to the bridge drivers and at least sdhci(4) currently
is hardcoding 1 s as timeout for all command types unconditionally.
Let alone already available return codes often not being checked in
the MMC layer ...
- Add an IOCTL interface to mmcsd(4); this is sufficiently compatible
with Linux so that the GNU mmc-utils can be ported to and used with
FreeBSD (note that due to the remaining deficiencies outlined above
SANITIZE operations issued by/with `mmc` currently most likely will
fail). These latter will be added to ports as sysutils/mmc-utils in
a bit. Among others, the `mmc` tool of the GNU mmc-utils allows for
partitioning eMMC devices (tested working).
- For devices following the eMMC specification v4.41 or later, year 0
is 2013 rather than 1997; so correct this for assembling the device
ID string properly.
- Let mmcsd.ko depend on mmc.ko. Additionally, bump MMC_VERSION as at
least for some of the above a matching pair is required.
- In the ACPI front-end of sdhci(4) describe the Intel eMMC and SDXC
controllers as such in order to match the PCI one.
Additionally, in the entry for the 80860F14 SDXC controller remove
the eMMC-only SDHCI_QUIRK_INTEL_POWER_UP_RESET.
OKed by: imp
Submitted by: ian (mmc_switch_status() implementation)
2017-03-16 22:23:04 +00:00
|
|
|
/* Controller doesn't allow access boot partitions. */
|
|
|
|
|
#define SDHCI_QUIRK_BOOT_NOACC (1 << 21)
|
|
|
|
|
/* Controller waits for busy responses. */
|
|
|
|
|
#define SDHCI_QUIRK_WAIT_WHILE_BUSY (1 << 22)
|
o Add support for eMMC DDR bus speed mode at 52 MHz to sdhci(4) and
mmc(4). For the most part, this consists of support for:
- Switching the signal voltage (VCCQ) to 1.8 V or (if supported
by the host controller) to 1.2 V,
- setting the UHS mode as appropriate in the SDHCI_HOST_CONTROL2
register,
- setting the power class in the eMMC device according to the
core supply voltage (VCC),
- using different bits for enabling a bus width of 4 and 8 bits
in the the eMMC device at DDR or higher timings respectively,
- arbitrating timings faster than high speed if there actually
are additional devices on the same MMC bus.
Given that support for DDR52 is not denoted by SDHCI capability
registers, availability of that timing is indicated by a new
quirk SDHCI_QUIRK_MMC_DDR52 and only enabled for Intel SDHCI
controllers so far. Generally, what it takes for a sdhci(4)
front-end to enable support for DDR52 is to hook up the bridge
method mmcbr_switch_vccq (which especially for 1.2 V signaling
support is chip/board specific) and the sdhci_set_uhs_timing
sdhci(4) method.
As a side-effect, this change also fixes communication with
some eMMC devices at SDR high speed mode with 52 MHz due to
the signaling voltage and UHS bits in the SDHCI controller no
longer being left in an inappropriate state.
Compared to 52 MHz at SDR high speed which typically yields
~45 MB/s with the eMMC chips tested, throughput goes up to
~80 MB/s at DDR52.
Additionally, this change already adds infrastructure and quite
some code for modes up to HS400ES and SDR104 respectively (I did
not want to add to much stuff at a time, though). Essentially,
what is still missing in order to be able to activate support
for these latter is is support for and handling of (re-)tuning.
o In sdhci(4), add two tunables hw.sdhci.quirk_clear as well as
hw.sdhci.quirk_set, which (when hooked up in the front-end)
allow to set/clear sdhci(4) quirks for debugging and testing
purposes. However, especially for SDHCI controllers on the
PCI bus which have no specific support code so far and, thus,
are picked up as generic SDHCI controllers, hw.sdhci.quirk_set
allows for setting the necessary quirks (if required).
o In mmc(4), check and handle the return values of some more
function calls instead of assuming that everything went right.
In case failures actually are not problematic, indicate that
by casting the return value to void.
Reviewed by: jmcneill
2017-03-19 23:27:17 +00:00
|
|
|
/* Controller supports eMMC DDR52 mode. */
|
|
|
|
|
#define SDHCI_QUIRK_MMC_DDR52 (1 << 23)
|
|
|
|
|
/* Controller support for UHS DDR50 mode is broken. */
|
|
|
|
|
#define SDHCI_QUIRK_BROKEN_UHS_DDR50 (1 << 24)
|
|
|
|
|
/* Controller support for eMMC HS200 mode is broken. */
|
|
|
|
|
#define SDHCI_QUIRK_BROKEN_MMC_HS200 (1 << 25)
|
|
|
|
|
/* Controller reports support for eMMC HS400 mode as SDHCI_CAN_MMC_HS400. */
|
|
|
|
|
#define SDHCI_QUIRK_CAPS_BIT63_FOR_MMC_HS400 (1 << 26)
|
|
|
|
|
/* Controller support for SDHCI_CTRL2_PRESET_VALUE is broken. */
|
|
|
|
|
#define SDHCI_QUIRK_PRESET_VALUE_BROKEN (1 << 27)
|
2017-05-09 19:01:57 +00:00
|
|
|
/* Controller does not support or the support for ACMD12 is broken. */
|
|
|
|
|
#define SDHCI_QUIRK_BROKEN_AUTO_STOP (1 << 28)
|
2012-02-09 10:20:41 +00:00
|
|
|
|
2008-10-21 20:33:40 +00:00
|
|
|
/*
|
|
|
|
|
* Controller registers
|
|
|
|
|
*/
|
2017-02-04 19:35:38 +00:00
|
|
|
#define SDHCI_DMA_ADDRESS 0x00
|
|
|
|
|
|
|
|
|
|
#define SDHCI_BLOCK_SIZE 0x04
|
|
|
|
|
#define SDHCI_MAKE_BLKSZ(dma, blksz) (((dma & 0x7) << 12) | (blksz & 0xFFF))
|
|
|
|
|
|
|
|
|
|
#define SDHCI_BLOCK_COUNT 0x06
|
|
|
|
|
|
|
|
|
|
#define SDHCI_ARGUMENT 0x08
|
|
|
|
|
|
|
|
|
|
#define SDHCI_TRANSFER_MODE 0x0C
|
|
|
|
|
#define SDHCI_TRNS_DMA 0x01
|
|
|
|
|
#define SDHCI_TRNS_BLK_CNT_EN 0x02
|
|
|
|
|
#define SDHCI_TRNS_ACMD12 0x04
|
|
|
|
|
#define SDHCI_TRNS_READ 0x10
|
|
|
|
|
#define SDHCI_TRNS_MULTI 0x20
|
|
|
|
|
|
|
|
|
|
#define SDHCI_COMMAND_FLAGS 0x0E
|
|
|
|
|
#define SDHCI_CMD_RESP_NONE 0x00
|
|
|
|
|
#define SDHCI_CMD_RESP_LONG 0x01
|
|
|
|
|
#define SDHCI_CMD_RESP_SHORT 0x02
|
|
|
|
|
#define SDHCI_CMD_RESP_SHORT_BUSY 0x03
|
|
|
|
|
#define SDHCI_CMD_RESP_MASK 0x03
|
|
|
|
|
#define SDHCI_CMD_CRC 0x08
|
|
|
|
|
#define SDHCI_CMD_INDEX 0x10
|
|
|
|
|
#define SDHCI_CMD_DATA 0x20
|
|
|
|
|
#define SDHCI_CMD_TYPE_NORMAL 0x00
|
|
|
|
|
#define SDHCI_CMD_TYPE_SUSPEND 0x40
|
|
|
|
|
#define SDHCI_CMD_TYPE_RESUME 0x80
|
|
|
|
|
#define SDHCI_CMD_TYPE_ABORT 0xc0
|
|
|
|
|
#define SDHCI_CMD_TYPE_MASK 0xc0
|
|
|
|
|
|
|
|
|
|
#define SDHCI_COMMAND 0x0F
|
|
|
|
|
|
|
|
|
|
#define SDHCI_RESPONSE 0x10
|
|
|
|
|
|
|
|
|
|
#define SDHCI_BUFFER 0x20
|
|
|
|
|
|
|
|
|
|
#define SDHCI_PRESENT_STATE 0x24
|
|
|
|
|
#define SDHCI_CMD_INHIBIT 0x00000001
|
|
|
|
|
#define SDHCI_DAT_INHIBIT 0x00000002
|
|
|
|
|
#define SDHCI_DAT_ACTIVE 0x00000004
|
|
|
|
|
#define SDHCI_RETUNE_REQUEST 0x00000008
|
|
|
|
|
#define SDHCI_DOING_WRITE 0x00000100
|
|
|
|
|
#define SDHCI_DOING_READ 0x00000200
|
|
|
|
|
#define SDHCI_SPACE_AVAILABLE 0x00000400
|
|
|
|
|
#define SDHCI_DATA_AVAILABLE 0x00000800
|
|
|
|
|
#define SDHCI_CARD_PRESENT 0x00010000
|
|
|
|
|
#define SDHCI_CARD_STABLE 0x00020000
|
|
|
|
|
#define SDHCI_CARD_PIN 0x00040000
|
|
|
|
|
#define SDHCI_WRITE_PROTECT 0x00080000
|
|
|
|
|
#define SDHCI_STATE_DAT_MASK 0x00f00000
|
|
|
|
|
#define SDHCI_STATE_CMD 0x01000000
|
|
|
|
|
|
|
|
|
|
#define SDHCI_HOST_CONTROL 0x28
|
|
|
|
|
#define SDHCI_CTRL_LED 0x01
|
|
|
|
|
#define SDHCI_CTRL_4BITBUS 0x02
|
|
|
|
|
#define SDHCI_CTRL_HISPD 0x04
|
|
|
|
|
#define SDHCI_CTRL_SDMA 0x08
|
|
|
|
|
#define SDHCI_CTRL_ADMA2 0x10
|
|
|
|
|
#define SDHCI_CTRL_ADMA264 0x18
|
|
|
|
|
#define SDHCI_CTRL_DMA_MASK 0x18
|
|
|
|
|
#define SDHCI_CTRL_8BITBUS 0x20
|
|
|
|
|
#define SDHCI_CTRL_CARD_DET 0x40
|
|
|
|
|
#define SDHCI_CTRL_FORCE_CARD 0x80
|
|
|
|
|
|
|
|
|
|
#define SDHCI_POWER_CONTROL 0x29
|
|
|
|
|
#define SDHCI_POWER_ON 0x01
|
|
|
|
|
#define SDHCI_POWER_180 0x0A
|
|
|
|
|
#define SDHCI_POWER_300 0x0C
|
|
|
|
|
#define SDHCI_POWER_330 0x0E
|
|
|
|
|
|
|
|
|
|
#define SDHCI_BLOCK_GAP_CONTROL 0x2A
|
|
|
|
|
|
|
|
|
|
#define SDHCI_WAKE_UP_CONTROL 0x2B
|
|
|
|
|
|
|
|
|
|
#define SDHCI_CLOCK_CONTROL 0x2C
|
|
|
|
|
#define SDHCI_DIVIDER_MASK 0xff
|
|
|
|
|
#define SDHCI_DIVIDER_MASK_LEN 8
|
|
|
|
|
#define SDHCI_DIVIDER_SHIFT 8
|
|
|
|
|
#define SDHCI_DIVIDER_HI_MASK 3
|
|
|
|
|
#define SDHCI_DIVIDER_HI_SHIFT 6
|
|
|
|
|
#define SDHCI_CLOCK_CARD_EN 0x0004
|
|
|
|
|
#define SDHCI_CLOCK_INT_STABLE 0x0002
|
|
|
|
|
#define SDHCI_CLOCK_INT_EN 0x0001
|
|
|
|
|
#define SDHCI_DIVIDERS_MASK \
|
2016-05-26 02:55:41 +00:00
|
|
|
((SDHCI_DIVIDER_MASK << SDHCI_DIVIDER_SHIFT) | \
|
|
|
|
|
(SDHCI_DIVIDER_HI_MASK << SDHCI_DIVIDER_HI_SHIFT))
|
2008-10-21 20:33:40 +00:00
|
|
|
|
2017-02-04 19:35:38 +00:00
|
|
|
#define SDHCI_TIMEOUT_CONTROL 0x2E
|
|
|
|
|
|
|
|
|
|
#define SDHCI_SOFTWARE_RESET 0x2F
|
|
|
|
|
#define SDHCI_RESET_ALL 0x01
|
|
|
|
|
#define SDHCI_RESET_CMD 0x02
|
|
|
|
|
#define SDHCI_RESET_DATA 0x04
|
|
|
|
|
|
|
|
|
|
#define SDHCI_INT_STATUS 0x30
|
|
|
|
|
#define SDHCI_INT_ENABLE 0x34
|
|
|
|
|
#define SDHCI_SIGNAL_ENABLE 0x38
|
|
|
|
|
#define SDHCI_INT_RESPONSE 0x00000001
|
|
|
|
|
#define SDHCI_INT_DATA_END 0x00000002
|
|
|
|
|
#define SDHCI_INT_BLOCK_GAP 0x00000004
|
|
|
|
|
#define SDHCI_INT_DMA_END 0x00000008
|
|
|
|
|
#define SDHCI_INT_SPACE_AVAIL 0x00000010
|
|
|
|
|
#define SDHCI_INT_DATA_AVAIL 0x00000020
|
|
|
|
|
#define SDHCI_INT_CARD_INSERT 0x00000040
|
|
|
|
|
#define SDHCI_INT_CARD_REMOVE 0x00000080
|
|
|
|
|
#define SDHCI_INT_CARD_INT 0x00000100
|
|
|
|
|
#define SDHCI_INT_INT_A 0x00000200
|
|
|
|
|
#define SDHCI_INT_INT_B 0x00000400
|
|
|
|
|
#define SDHCI_INT_INT_C 0x00000800
|
|
|
|
|
#define SDHCI_INT_RETUNE 0x00001000
|
|
|
|
|
#define SDHCI_INT_ERROR 0x00008000
|
|
|
|
|
#define SDHCI_INT_TIMEOUT 0x00010000
|
|
|
|
|
#define SDHCI_INT_CRC 0x00020000
|
|
|
|
|
#define SDHCI_INT_END_BIT 0x00040000
|
|
|
|
|
#define SDHCI_INT_INDEX 0x00080000
|
|
|
|
|
#define SDHCI_INT_DATA_TIMEOUT 0x00100000
|
|
|
|
|
#define SDHCI_INT_DATA_CRC 0x00200000
|
|
|
|
|
#define SDHCI_INT_DATA_END_BIT 0x00400000
|
|
|
|
|
#define SDHCI_INT_BUS_POWER 0x00800000
|
|
|
|
|
#define SDHCI_INT_ACMD12ERR 0x01000000
|
|
|
|
|
#define SDHCI_INT_ADMAERR 0x02000000
|
|
|
|
|
#define SDHCI_INT_TUNEERR 0x04000000
|
|
|
|
|
|
|
|
|
|
#define SDHCI_INT_NORMAL_MASK 0x00007FFF
|
|
|
|
|
#define SDHCI_INT_ERROR_MASK 0xFFFF8000
|
|
|
|
|
|
|
|
|
|
#define SDHCI_INT_CMD_ERROR_MASK (SDHCI_INT_TIMEOUT | \
|
2008-10-21 20:33:40 +00:00
|
|
|
SDHCI_INT_CRC | SDHCI_INT_END_BIT | SDHCI_INT_INDEX)
|
2014-12-20 00:37:56 +00:00
|
|
|
|
2017-02-04 19:35:38 +00:00
|
|
|
#define SDHCI_INT_CMD_MASK (SDHCI_INT_RESPONSE | SDHCI_INT_CMD_ERROR_MASK)
|
2014-12-20 00:37:56 +00:00
|
|
|
|
2017-02-04 19:35:38 +00:00
|
|
|
#define SDHCI_INT_DATA_MASK (SDHCI_INT_DATA_END | SDHCI_INT_DMA_END | \
|
2008-10-21 20:33:40 +00:00
|
|
|
SDHCI_INT_DATA_AVAIL | SDHCI_INT_SPACE_AVAIL | \
|
|
|
|
|
SDHCI_INT_DATA_TIMEOUT | SDHCI_INT_DATA_CRC | \
|
|
|
|
|
SDHCI_INT_DATA_END_BIT)
|
|
|
|
|
|
2017-02-04 19:35:38 +00:00
|
|
|
#define SDHCI_ACMD12_ERR 0x3C
|
2017-03-16 22:42:17 +00:00
|
|
|
|
2017-02-04 19:35:38 +00:00
|
|
|
#define SDHCI_HOST_CONTROL2 0x3E
|
2017-03-16 22:42:17 +00:00
|
|
|
#define SDHCI_CTRL2_PRESET_VALUE 0x8000
|
|
|
|
|
#define SDHCI_CTRL2_ASYNC_INTR 0x4000
|
2017-07-26 22:04:23 +00:00
|
|
|
#define SDHCI_CTRL2_64BIT_ENABLE 0x2000
|
|
|
|
|
#define SDHCI_CTRL2_HOST_V4_ENABLE 0x1000
|
|
|
|
|
#define SDHCI_CTRL2_CMD23_ENABLE 0x0800
|
|
|
|
|
#define SDHCI_CTRL2_ADMA2_LENGTH_MODE 0x0400
|
|
|
|
|
#define SDHCI_CTRL2_UHS2_IFACE_ENABLE 0x0100
|
2017-03-16 22:42:17 +00:00
|
|
|
#define SDHCI_CTRL2_SAMPLING_CLOCK 0x0080
|
|
|
|
|
#define SDHCI_CTRL2_EXEC_TUNING 0x0040
|
|
|
|
|
#define SDHCI_CTRL2_DRIVER_TYPE_MASK 0x0030
|
|
|
|
|
#define SDHCI_CTRL2_DRIVER_TYPE_B 0x0000
|
|
|
|
|
#define SDHCI_CTRL2_DRIVER_TYPE_A 0x0010
|
|
|
|
|
#define SDHCI_CTRL2_DRIVER_TYPE_C 0x0020
|
|
|
|
|
#define SDHCI_CTRL2_DRIVER_TYPE_D 0x0030
|
|
|
|
|
#define SDHCI_CTRL2_S18_ENABLE 0x0008
|
|
|
|
|
#define SDHCI_CTRL2_UHS_MASK 0x0007
|
|
|
|
|
#define SDHCI_CTRL2_UHS_SDR12 0x0000
|
|
|
|
|
#define SDHCI_CTRL2_UHS_SDR25 0x0001
|
|
|
|
|
#define SDHCI_CTRL2_UHS_SDR50 0x0002
|
|
|
|
|
#define SDHCI_CTRL2_UHS_SDR104 0x0003
|
|
|
|
|
#define SDHCI_CTRL2_UHS_DDR50 0x0004
|
o Add support for eMMC DDR bus speed mode at 52 MHz to sdhci(4) and
mmc(4). For the most part, this consists of support for:
- Switching the signal voltage (VCCQ) to 1.8 V or (if supported
by the host controller) to 1.2 V,
- setting the UHS mode as appropriate in the SDHCI_HOST_CONTROL2
register,
- setting the power class in the eMMC device according to the
core supply voltage (VCC),
- using different bits for enabling a bus width of 4 and 8 bits
in the the eMMC device at DDR or higher timings respectively,
- arbitrating timings faster than high speed if there actually
are additional devices on the same MMC bus.
Given that support for DDR52 is not denoted by SDHCI capability
registers, availability of that timing is indicated by a new
quirk SDHCI_QUIRK_MMC_DDR52 and only enabled for Intel SDHCI
controllers so far. Generally, what it takes for a sdhci(4)
front-end to enable support for DDR52 is to hook up the bridge
method mmcbr_switch_vccq (which especially for 1.2 V signaling
support is chip/board specific) and the sdhci_set_uhs_timing
sdhci(4) method.
As a side-effect, this change also fixes communication with
some eMMC devices at SDR high speed mode with 52 MHz due to
the signaling voltage and UHS bits in the SDHCI controller no
longer being left in an inappropriate state.
Compared to 52 MHz at SDR high speed which typically yields
~45 MB/s with the eMMC chips tested, throughput goes up to
~80 MB/s at DDR52.
Additionally, this change already adds infrastructure and quite
some code for modes up to HS400ES and SDR104 respectively (I did
not want to add to much stuff at a time, though). Essentially,
what is still missing in order to be able to activate support
for these latter is is support for and handling of (re-)tuning.
o In sdhci(4), add two tunables hw.sdhci.quirk_clear as well as
hw.sdhci.quirk_set, which (when hooked up in the front-end)
allow to set/clear sdhci(4) quirks for debugging and testing
purposes. However, especially for SDHCI controllers on the
PCI bus which have no specific support code so far and, thus,
are picked up as generic SDHCI controllers, hw.sdhci.quirk_set
allows for setting the necessary quirks (if required).
o In mmc(4), check and handle the return values of some more
function calls instead of assuming that everything went right.
In case failures actually are not problematic, indicate that
by casting the return value to void.
Reviewed by: jmcneill
2017-03-19 23:27:17 +00:00
|
|
|
#define SDHCI_CTRL2_MMC_HS400 0x0005 /* non-standard */
|
2017-02-04 19:35:38 +00:00
|
|
|
|
|
|
|
|
#define SDHCI_CAPABILITIES 0x40
|
|
|
|
|
#define SDHCI_TIMEOUT_CLK_MASK 0x0000003F
|
|
|
|
|
#define SDHCI_TIMEOUT_CLK_SHIFT 0
|
|
|
|
|
#define SDHCI_TIMEOUT_CLK_UNIT 0x00000080
|
|
|
|
|
#define SDHCI_CLOCK_BASE_MASK 0x00003F00
|
|
|
|
|
#define SDHCI_CLOCK_V3_BASE_MASK 0x0000FF00
|
|
|
|
|
#define SDHCI_CLOCK_BASE_SHIFT 8
|
|
|
|
|
#define SDHCI_MAX_BLOCK_MASK 0x00030000
|
|
|
|
|
#define SDHCI_MAX_BLOCK_SHIFT 16
|
|
|
|
|
#define SDHCI_CAN_DO_8BITBUS 0x00040000
|
|
|
|
|
#define SDHCI_CAN_DO_ADMA2 0x00080000
|
|
|
|
|
#define SDHCI_CAN_DO_HISPD 0x00200000
|
|
|
|
|
#define SDHCI_CAN_DO_DMA 0x00400000
|
|
|
|
|
#define SDHCI_CAN_DO_SUSPEND 0x00800000
|
|
|
|
|
#define SDHCI_CAN_VDD_330 0x01000000
|
|
|
|
|
#define SDHCI_CAN_VDD_300 0x02000000
|
|
|
|
|
#define SDHCI_CAN_VDD_180 0x04000000
|
|
|
|
|
#define SDHCI_CAN_DO_64BIT 0x10000000
|
|
|
|
|
#define SDHCI_CAN_ASYNC_INTR 0x20000000
|
2017-03-16 22:42:17 +00:00
|
|
|
#define SDHCI_SLOTTYPE_MASK 0xC0000000
|
|
|
|
|
#define SDHCI_SLOTTYPE_REMOVABLE 0x00000000
|
|
|
|
|
#define SDHCI_SLOTTYPE_EMBEDDED 0x40000000
|
|
|
|
|
#define SDHCI_SLOTTYPE_SHARED 0x80000000
|
2017-02-04 19:35:38 +00:00
|
|
|
|
|
|
|
|
#define SDHCI_CAPABILITIES2 0x44
|
|
|
|
|
#define SDHCI_CAN_SDR50 0x00000001
|
|
|
|
|
#define SDHCI_CAN_SDR104 0x00000002
|
|
|
|
|
#define SDHCI_CAN_DDR50 0x00000004
|
|
|
|
|
#define SDHCI_CAN_DRIVE_TYPE_A 0x00000010
|
2017-03-16 22:42:17 +00:00
|
|
|
#define SDHCI_CAN_DRIVE_TYPE_C 0x00000020
|
|
|
|
|
#define SDHCI_CAN_DRIVE_TYPE_D 0x00000040
|
2017-02-04 19:35:38 +00:00
|
|
|
#define SDHCI_RETUNE_CNT_MASK 0x00000F00
|
|
|
|
|
#define SDHCI_RETUNE_CNT_SHIFT 8
|
|
|
|
|
#define SDHCI_TUNE_SDR50 0x00002000
|
|
|
|
|
#define SDHCI_RETUNE_MODES_MASK 0x0000C000
|
|
|
|
|
#define SDHCI_RETUNE_MODES_SHIFT 14
|
|
|
|
|
#define SDHCI_CLOCK_MULT_MASK 0x00FF0000
|
|
|
|
|
#define SDHCI_CLOCK_MULT_SHIFT 16
|
o Add support for eMMC DDR bus speed mode at 52 MHz to sdhci(4) and
mmc(4). For the most part, this consists of support for:
- Switching the signal voltage (VCCQ) to 1.8 V or (if supported
by the host controller) to 1.2 V,
- setting the UHS mode as appropriate in the SDHCI_HOST_CONTROL2
register,
- setting the power class in the eMMC device according to the
core supply voltage (VCC),
- using different bits for enabling a bus width of 4 and 8 bits
in the the eMMC device at DDR or higher timings respectively,
- arbitrating timings faster than high speed if there actually
are additional devices on the same MMC bus.
Given that support for DDR52 is not denoted by SDHCI capability
registers, availability of that timing is indicated by a new
quirk SDHCI_QUIRK_MMC_DDR52 and only enabled for Intel SDHCI
controllers so far. Generally, what it takes for a sdhci(4)
front-end to enable support for DDR52 is to hook up the bridge
method mmcbr_switch_vccq (which especially for 1.2 V signaling
support is chip/board specific) and the sdhci_set_uhs_timing
sdhci(4) method.
As a side-effect, this change also fixes communication with
some eMMC devices at SDR high speed mode with 52 MHz due to
the signaling voltage and UHS bits in the SDHCI controller no
longer being left in an inappropriate state.
Compared to 52 MHz at SDR high speed which typically yields
~45 MB/s with the eMMC chips tested, throughput goes up to
~80 MB/s at DDR52.
Additionally, this change already adds infrastructure and quite
some code for modes up to HS400ES and SDR104 respectively (I did
not want to add to much stuff at a time, though). Essentially,
what is still missing in order to be able to activate support
for these latter is is support for and handling of (re-)tuning.
o In sdhci(4), add two tunables hw.sdhci.quirk_clear as well as
hw.sdhci.quirk_set, which (when hooked up in the front-end)
allow to set/clear sdhci(4) quirks for debugging and testing
purposes. However, especially for SDHCI controllers on the
PCI bus which have no specific support code so far and, thus,
are picked up as generic SDHCI controllers, hw.sdhci.quirk_set
allows for setting the necessary quirks (if required).
o In mmc(4), check and handle the return values of some more
function calls instead of assuming that everything went right.
In case failures actually are not problematic, indicate that
by casting the return value to void.
Reviewed by: jmcneill
2017-03-19 23:27:17 +00:00
|
|
|
#define SDHCI_CAN_MMC_HS400 0x80000000 /* non-standard */
|
2017-02-04 19:35:38 +00:00
|
|
|
|
|
|
|
|
#define SDHCI_MAX_CURRENT 0x48
|
|
|
|
|
#define SDHCI_FORCE_AUTO_EVENT 0x50
|
|
|
|
|
#define SDHCI_FORCE_INTR_EVENT 0x52
|
2017-03-16 22:42:17 +00:00
|
|
|
|
2017-02-04 19:35:38 +00:00
|
|
|
#define SDHCI_ADMA_ERR 0x54
|
2017-03-16 22:42:17 +00:00
|
|
|
#define SDHCI_ADMA_ERR_LENGTH 0x04
|
|
|
|
|
#define SDHCI_ADMA_ERR_STATE_MASK 0x03
|
|
|
|
|
#define SDHCI_ADMA_ERR_STATE_STOP 0x00
|
|
|
|
|
#define SDHCI_ADMA_ERR_STATE_FDS 0x01
|
|
|
|
|
#define SDHCI_ADMA_ERR_STATE_TFR 0x03
|
|
|
|
|
|
|
|
|
|
#define SDHCI_ADMA_ADDRESS_LO 0x58
|
2017-02-04 19:35:38 +00:00
|
|
|
#define SDHCI_ADMA_ADDRESS_HI 0x5C
|
2017-03-16 22:42:17 +00:00
|
|
|
|
2017-02-04 19:35:38 +00:00
|
|
|
#define SDHCI_PRESET_VALUE 0x60
|
|
|
|
|
#define SDHCI_SHARED_BUS_CTRL 0xE0
|
|
|
|
|
|
|
|
|
|
#define SDHCI_SLOT_INT_STATUS 0xFC
|
|
|
|
|
|
|
|
|
|
#define SDHCI_HOST_VERSION 0xFE
|
|
|
|
|
#define SDHCI_VENDOR_VER_MASK 0xFF00
|
|
|
|
|
#define SDHCI_VENDOR_VER_SHIFT 8
|
|
|
|
|
#define SDHCI_SPEC_VER_MASK 0x00FF
|
|
|
|
|
#define SDHCI_SPEC_VER_SHIFT 0
|
2012-10-29 17:21:58 +00:00
|
|
|
#define SDHCI_SPEC_100 0
|
|
|
|
|
#define SDHCI_SPEC_200 1
|
|
|
|
|
#define SDHCI_SPEC_300 2
|
2017-03-16 22:42:17 +00:00
|
|
|
#define SDHCI_SPEC_400 3
|
2017-07-26 22:04:23 +00:00
|
|
|
#define SDHCI_SPEC_410 4
|
|
|
|
|
#define SDHCI_SPEC_420 5
|
2012-10-16 01:10:43 +00:00
|
|
|
|
2014-08-31 17:56:54 +00:00
|
|
|
SYSCTL_DECL(_hw_sdhci);
|
|
|
|
|
|
o Add support for eMMC DDR bus speed mode at 52 MHz to sdhci(4) and
mmc(4). For the most part, this consists of support for:
- Switching the signal voltage (VCCQ) to 1.8 V or (if supported
by the host controller) to 1.2 V,
- setting the UHS mode as appropriate in the SDHCI_HOST_CONTROL2
register,
- setting the power class in the eMMC device according to the
core supply voltage (VCC),
- using different bits for enabling a bus width of 4 and 8 bits
in the the eMMC device at DDR or higher timings respectively,
- arbitrating timings faster than high speed if there actually
are additional devices on the same MMC bus.
Given that support for DDR52 is not denoted by SDHCI capability
registers, availability of that timing is indicated by a new
quirk SDHCI_QUIRK_MMC_DDR52 and only enabled for Intel SDHCI
controllers so far. Generally, what it takes for a sdhci(4)
front-end to enable support for DDR52 is to hook up the bridge
method mmcbr_switch_vccq (which especially for 1.2 V signaling
support is chip/board specific) and the sdhci_set_uhs_timing
sdhci(4) method.
As a side-effect, this change also fixes communication with
some eMMC devices at SDR high speed mode with 52 MHz due to
the signaling voltage and UHS bits in the SDHCI controller no
longer being left in an inappropriate state.
Compared to 52 MHz at SDR high speed which typically yields
~45 MB/s with the eMMC chips tested, throughput goes up to
~80 MB/s at DDR52.
Additionally, this change already adds infrastructure and quite
some code for modes up to HS400ES and SDR104 respectively (I did
not want to add to much stuff at a time, though). Essentially,
what is still missing in order to be able to activate support
for these latter is is support for and handling of (re-)tuning.
o In sdhci(4), add two tunables hw.sdhci.quirk_clear as well as
hw.sdhci.quirk_set, which (when hooked up in the front-end)
allow to set/clear sdhci(4) quirks for debugging and testing
purposes. However, especially for SDHCI controllers on the
PCI bus which have no specific support code so far and, thus,
are picked up as generic SDHCI controllers, hw.sdhci.quirk_set
allows for setting the necessary quirks (if required).
o In mmc(4), check and handle the return values of some more
function calls instead of assuming that everything went right.
In case failures actually are not problematic, indicate that
by casting the return value to void.
Reviewed by: jmcneill
2017-03-19 23:27:17 +00:00
|
|
|
extern u_int sdhci_quirk_clear;
|
|
|
|
|
extern u_int sdhci_quirk_set;
|
|
|
|
|
|
2012-10-16 01:10:43 +00:00
|
|
|
struct sdhci_slot {
|
o Add support for eMMC HS200 and HS400 bus speed modes at 200 MHz to
sdhci(4), mmc(4) and mmcsd(4). For the most part, this consists of:
- Correcting and extending the infrastructure for negotiating and
enabling post-DDR52 modes already added as part of r315598. In
fact, HS400ES now should work as well but hasn't been activated
due to lack of corresponding hardware.
- Adding support executing standard SDHCI initial tuning as well
as re-tuning as required for eMMC HS200/HS400 and the fast UHS-I
SD card modes. Currently, corresponding methods are only hooked
up to the ACPI and PCI front-ends of sdhci(4), though. Moreover,
sdhci(4) won't offer any modes requiring (re-)tuning to the MMC/SD
layer in order to not break operations with other sdhci(4) front-
ends. Likewise, sdhci(4) now no longer offers modes requiring the
set_uhs_timing method introduced in r315598 to be implemented/
hooked up (previously, this method was used with DDR52 only, which
in turn is only available with Intel controllers so far, i. e. no
such limitation was necessary before). Similarly for 1.2/1.8 V VCCQ
support and the switch_vccq method.
- Addition of locking to the IOCTL half of mmcsd(4) to prevent races
with detachment and suspension, especially since it's required to
immediately switch away from RPMB partitions again after an access
to these (so re-tuning can take place anew, given that the current
eMMC specification v5.1 doesn't allow tuning commands to be issued
with a RPMB partition selected). Therefore, the existing part_mtx
lock in the mmcsd(4) softc is additionally renamed to disk_mtx in
order to denote that it only refers to the disk(9) half, likewise
for corresponding macros.
On the system where the addition of DDR52 support increased the read
throughput to ~80 MB/s (from ~45 MB/s at high speed), HS200 yields
~154 MB/s and HS400 ~187 MB/s, i. e. performance now has more than
quadrupled compared to pre-r315598.
Also, with the advent of (re-)tuning support, most infrastructure
necessary for SD card UHS-I modes up to SDR104 now is also in place.
Note, though, that the standard SDHCI way of (re-)tuning is special
in several ways, which also is why sending the actual tuning requests
to the device is part of sdhci(4). SDHCI implementations not following
the specification, MMC and non-SDHCI SD card controllers likely will
use a generic implementation in the MMC/SD layer for executing tuning,
which hasn't been written so far, though.
However, in fact this isn't a feature-only change; there are boards
based on Intel Bay Trail where DDR52 is problematic and the suggested
workaround is to use HS200 mode instead. So far exact details are
unknown, however, i. e. whether that's due to a defect in these SoCs
or on the boards.
Moreover, due to the above changes requiring to be aware of possible
MMC siblings in the fast path of mmc(4), corresponding information
now is cached in mmc_softc. As a side-effect, mmc_calculate_clock(),
mmc_delete_cards(), mmc_discover_cards() and mmc_rescan_cards() now
all are guaranteed to operate on the same set of devices as there no
longer is any use of device_get_children(9), which can fail in low
memory situations. Likewise, mmc_calculate_clock() now longer will
trigger a panic due to the latter.
o Fix a bug in the failure reporting of mmcsd_delete(); in case of an
error when the starting block of a previously stored erase request
is used (in order to be able to erase a full erase sector worth of
data), the starting block of the newly supplied bio_pblkno has to be
returned for indicating no progress. Otherwise, upper layers might
be told that a negative number of BIOs have been completed, leading
to a panic.
o Fix 2 bugs on resume:
- Things done in fork1(9) like the acquisition of an SX lock or the
sleepable memory allocation are incompatible with a MTX_DEF taken.
Thus, mmcsd_resume() must not call kproc_create(9), which in turn
uses fork1(9), with the disk_mtx (formerly part_mtx) held.
- In mmc_suspend(), the bus is powered down, which in the typical
case of a device being selected at the time of suspension, causes
the device deselection as part of the bus acquisition by mmc(4) in
mmc_scan() to fail as the bus isn't powered up again before later
in mmc_go_discovery(). Thus, power down with the bus acquired in
mmc_suspend(), which will trigger the deselection up-front.
o Fix a memory leak in mmcsd_ioctl() in case copyin(9) fails. [1]
o Fix missing variable initialization in mmc_switch_status(). [2]
o Fix R1_SWITCH_ERROR detection in mmc_switch_status(). [3]
o Handle the case of device_add_child(9) failing, for example due to
a memory shortage, gracefully in mmc(4) and sdhci(4), including not
leaking memory for the instance variables in case of mmc(4) (which
might or might not fix [4] as the latter problem has been discovered
independently).
o Handle the case of an unknown SD CSD version in mmc_decode_csd_sd()
gracefully instead of calling panic(9).
o Again, check and handle the return values of some additional function
calls in mmc(4) instead of assuming that everything went right or mark
non-fatal errors by casting the return value to void.
o Correct a typo in the Linux IOCTL compatibility; it should have been
MMC_IOC_MULTI_CMD rather than MMC_IOC_CMD_MULTI.
o Now that we are reaching ever faster speeds (more improvement in this
regard is to be expected when adding ADMA support to sdhci(4)), apply
a few micro-optimizations like predicting mmc(4) and sdhci(4) debugging
to be off or caching erase sector and maximum data sizes as well support
of block addressing in mmsd(4) (instead of doing 2 indirections on every
read/write request for determining the maximum data size for example).
Reported by: Coverity
CID: 1372612 [1], 1372624 [2], 1372594 [3], 1007069 [4]
2017-07-23 16:11:47 +00:00
|
|
|
struct mtx mtx; /* Slot mutex */
|
2012-10-16 01:10:43 +00:00
|
|
|
u_int quirks; /* Chip specific quirks */
|
2012-10-29 17:21:58 +00:00
|
|
|
u_int caps; /* Override SDHCI_CAPABILITIES */
|
o Add support for eMMC DDR bus speed mode at 52 MHz to sdhci(4) and
mmc(4). For the most part, this consists of support for:
- Switching the signal voltage (VCCQ) to 1.8 V or (if supported
by the host controller) to 1.2 V,
- setting the UHS mode as appropriate in the SDHCI_HOST_CONTROL2
register,
- setting the power class in the eMMC device according to the
core supply voltage (VCC),
- using different bits for enabling a bus width of 4 and 8 bits
in the the eMMC device at DDR or higher timings respectively,
- arbitrating timings faster than high speed if there actually
are additional devices on the same MMC bus.
Given that support for DDR52 is not denoted by SDHCI capability
registers, availability of that timing is indicated by a new
quirk SDHCI_QUIRK_MMC_DDR52 and only enabled for Intel SDHCI
controllers so far. Generally, what it takes for a sdhci(4)
front-end to enable support for DDR52 is to hook up the bridge
method mmcbr_switch_vccq (which especially for 1.2 V signaling
support is chip/board specific) and the sdhci_set_uhs_timing
sdhci(4) method.
As a side-effect, this change also fixes communication with
some eMMC devices at SDR high speed mode with 52 MHz due to
the signaling voltage and UHS bits in the SDHCI controller no
longer being left in an inappropriate state.
Compared to 52 MHz at SDR high speed which typically yields
~45 MB/s with the eMMC chips tested, throughput goes up to
~80 MB/s at DDR52.
Additionally, this change already adds infrastructure and quite
some code for modes up to HS400ES and SDR104 respectively (I did
not want to add to much stuff at a time, though). Essentially,
what is still missing in order to be able to activate support
for these latter is is support for and handling of (re-)tuning.
o In sdhci(4), add two tunables hw.sdhci.quirk_clear as well as
hw.sdhci.quirk_set, which (when hooked up in the front-end)
allow to set/clear sdhci(4) quirks for debugging and testing
purposes. However, especially for SDHCI controllers on the
PCI bus which have no specific support code so far and, thus,
are picked up as generic SDHCI controllers, hw.sdhci.quirk_set
allows for setting the necessary quirks (if required).
o In mmc(4), check and handle the return values of some more
function calls instead of assuming that everything went right.
In case failures actually are not problematic, indicate that
by casting the return value to void.
Reviewed by: jmcneill
2017-03-19 23:27:17 +00:00
|
|
|
u_int caps2; /* Override SDHCI_CAPABILITIES2 */
|
2012-10-16 01:10:43 +00:00
|
|
|
device_t bus; /* Bus device */
|
|
|
|
|
device_t dev; /* Slot device */
|
|
|
|
|
u_char num; /* Slot number */
|
|
|
|
|
u_char opt; /* Slot options */
|
2017-01-09 01:15:18 +00:00
|
|
|
#define SDHCI_HAVE_DMA 0x01
|
|
|
|
|
#define SDHCI_PLATFORM_TRANSFER 0x02
|
|
|
|
|
#define SDHCI_NON_REMOVABLE 0x04
|
o Add support for eMMC HS200 and HS400 bus speed modes at 200 MHz to
sdhci(4), mmc(4) and mmcsd(4). For the most part, this consists of:
- Correcting and extending the infrastructure for negotiating and
enabling post-DDR52 modes already added as part of r315598. In
fact, HS400ES now should work as well but hasn't been activated
due to lack of corresponding hardware.
- Adding support executing standard SDHCI initial tuning as well
as re-tuning as required for eMMC HS200/HS400 and the fast UHS-I
SD card modes. Currently, corresponding methods are only hooked
up to the ACPI and PCI front-ends of sdhci(4), though. Moreover,
sdhci(4) won't offer any modes requiring (re-)tuning to the MMC/SD
layer in order to not break operations with other sdhci(4) front-
ends. Likewise, sdhci(4) now no longer offers modes requiring the
set_uhs_timing method introduced in r315598 to be implemented/
hooked up (previously, this method was used with DDR52 only, which
in turn is only available with Intel controllers so far, i. e. no
such limitation was necessary before). Similarly for 1.2/1.8 V VCCQ
support and the switch_vccq method.
- Addition of locking to the IOCTL half of mmcsd(4) to prevent races
with detachment and suspension, especially since it's required to
immediately switch away from RPMB partitions again after an access
to these (so re-tuning can take place anew, given that the current
eMMC specification v5.1 doesn't allow tuning commands to be issued
with a RPMB partition selected). Therefore, the existing part_mtx
lock in the mmcsd(4) softc is additionally renamed to disk_mtx in
order to denote that it only refers to the disk(9) half, likewise
for corresponding macros.
On the system where the addition of DDR52 support increased the read
throughput to ~80 MB/s (from ~45 MB/s at high speed), HS200 yields
~154 MB/s and HS400 ~187 MB/s, i. e. performance now has more than
quadrupled compared to pre-r315598.
Also, with the advent of (re-)tuning support, most infrastructure
necessary for SD card UHS-I modes up to SDR104 now is also in place.
Note, though, that the standard SDHCI way of (re-)tuning is special
in several ways, which also is why sending the actual tuning requests
to the device is part of sdhci(4). SDHCI implementations not following
the specification, MMC and non-SDHCI SD card controllers likely will
use a generic implementation in the MMC/SD layer for executing tuning,
which hasn't been written so far, though.
However, in fact this isn't a feature-only change; there are boards
based on Intel Bay Trail where DDR52 is problematic and the suggested
workaround is to use HS200 mode instead. So far exact details are
unknown, however, i. e. whether that's due to a defect in these SoCs
or on the boards.
Moreover, due to the above changes requiring to be aware of possible
MMC siblings in the fast path of mmc(4), corresponding information
now is cached in mmc_softc. As a side-effect, mmc_calculate_clock(),
mmc_delete_cards(), mmc_discover_cards() and mmc_rescan_cards() now
all are guaranteed to operate on the same set of devices as there no
longer is any use of device_get_children(9), which can fail in low
memory situations. Likewise, mmc_calculate_clock() now longer will
trigger a panic due to the latter.
o Fix a bug in the failure reporting of mmcsd_delete(); in case of an
error when the starting block of a previously stored erase request
is used (in order to be able to erase a full erase sector worth of
data), the starting block of the newly supplied bio_pblkno has to be
returned for indicating no progress. Otherwise, upper layers might
be told that a negative number of BIOs have been completed, leading
to a panic.
o Fix 2 bugs on resume:
- Things done in fork1(9) like the acquisition of an SX lock or the
sleepable memory allocation are incompatible with a MTX_DEF taken.
Thus, mmcsd_resume() must not call kproc_create(9), which in turn
uses fork1(9), with the disk_mtx (formerly part_mtx) held.
- In mmc_suspend(), the bus is powered down, which in the typical
case of a device being selected at the time of suspension, causes
the device deselection as part of the bus acquisition by mmc(4) in
mmc_scan() to fail as the bus isn't powered up again before later
in mmc_go_discovery(). Thus, power down with the bus acquired in
mmc_suspend(), which will trigger the deselection up-front.
o Fix a memory leak in mmcsd_ioctl() in case copyin(9) fails. [1]
o Fix missing variable initialization in mmc_switch_status(). [2]
o Fix R1_SWITCH_ERROR detection in mmc_switch_status(). [3]
o Handle the case of device_add_child(9) failing, for example due to
a memory shortage, gracefully in mmc(4) and sdhci(4), including not
leaking memory for the instance variables in case of mmc(4) (which
might or might not fix [4] as the latter problem has been discovered
independently).
o Handle the case of an unknown SD CSD version in mmc_decode_csd_sd()
gracefully instead of calling panic(9).
o Again, check and handle the return values of some additional function
calls in mmc(4) instead of assuming that everything went right or mark
non-fatal errors by casting the return value to void.
o Correct a typo in the Linux IOCTL compatibility; it should have been
MMC_IOC_MULTI_CMD rather than MMC_IOC_CMD_MULTI.
o Now that we are reaching ever faster speeds (more improvement in this
regard is to be expected when adding ADMA support to sdhci(4)), apply
a few micro-optimizations like predicting mmc(4) and sdhci(4) debugging
to be off or caching erase sector and maximum data sizes as well support
of block addressing in mmsd(4) (instead of doing 2 indirections on every
read/write request for determining the maximum data size for example).
Reported by: Coverity
CID: 1372612 [1], 1372624 [2], 1372594 [3], 1007069 [4]
2017-07-23 16:11:47 +00:00
|
|
|
#define SDHCI_TUNING_SUPPORTED 0x08
|
|
|
|
|
#define SDHCI_TUNING_ENABLED 0x10
|
|
|
|
|
#define SDHCI_SDR50_NEEDS_TUNING 0x20
|
2017-07-26 22:04:23 +00:00
|
|
|
#define SDHCI_SLOT_EMBEDDED 0x40
|
2012-10-16 01:10:43 +00:00
|
|
|
u_char version;
|
2015-05-21 20:09:36 +00:00
|
|
|
int timeout; /* Transfer timeout */
|
2012-10-16 01:10:43 +00:00
|
|
|
uint32_t max_clk; /* Max possible freq */
|
|
|
|
|
uint32_t timeout_clk; /* Timeout freq */
|
2017-01-29 00:05:49 +00:00
|
|
|
bus_dma_tag_t dmatag;
|
|
|
|
|
bus_dmamap_t dmamap;
|
2012-10-16 01:10:43 +00:00
|
|
|
u_char *dmamem;
|
|
|
|
|
bus_addr_t paddr; /* DMA buffer address */
|
|
|
|
|
struct task card_task; /* Card presence check task */
|
2017-01-29 00:05:49 +00:00
|
|
|
struct timeout_task
|
2017-01-09 01:15:18 +00:00
|
|
|
card_delayed_task;/* Card insert delayed task */
|
|
|
|
|
struct callout card_poll_callout;/* Card present polling callout */
|
2014-02-15 20:45:53 +00:00
|
|
|
struct callout timeout_callout;/* Card command/data response timeout */
|
o Add support for eMMC HS200 and HS400 bus speed modes at 200 MHz to
sdhci(4), mmc(4) and mmcsd(4). For the most part, this consists of:
- Correcting and extending the infrastructure for negotiating and
enabling post-DDR52 modes already added as part of r315598. In
fact, HS400ES now should work as well but hasn't been activated
due to lack of corresponding hardware.
- Adding support executing standard SDHCI initial tuning as well
as re-tuning as required for eMMC HS200/HS400 and the fast UHS-I
SD card modes. Currently, corresponding methods are only hooked
up to the ACPI and PCI front-ends of sdhci(4), though. Moreover,
sdhci(4) won't offer any modes requiring (re-)tuning to the MMC/SD
layer in order to not break operations with other sdhci(4) front-
ends. Likewise, sdhci(4) now no longer offers modes requiring the
set_uhs_timing method introduced in r315598 to be implemented/
hooked up (previously, this method was used with DDR52 only, which
in turn is only available with Intel controllers so far, i. e. no
such limitation was necessary before). Similarly for 1.2/1.8 V VCCQ
support and the switch_vccq method.
- Addition of locking to the IOCTL half of mmcsd(4) to prevent races
with detachment and suspension, especially since it's required to
immediately switch away from RPMB partitions again after an access
to these (so re-tuning can take place anew, given that the current
eMMC specification v5.1 doesn't allow tuning commands to be issued
with a RPMB partition selected). Therefore, the existing part_mtx
lock in the mmcsd(4) softc is additionally renamed to disk_mtx in
order to denote that it only refers to the disk(9) half, likewise
for corresponding macros.
On the system where the addition of DDR52 support increased the read
throughput to ~80 MB/s (from ~45 MB/s at high speed), HS200 yields
~154 MB/s and HS400 ~187 MB/s, i. e. performance now has more than
quadrupled compared to pre-r315598.
Also, with the advent of (re-)tuning support, most infrastructure
necessary for SD card UHS-I modes up to SDR104 now is also in place.
Note, though, that the standard SDHCI way of (re-)tuning is special
in several ways, which also is why sending the actual tuning requests
to the device is part of sdhci(4). SDHCI implementations not following
the specification, MMC and non-SDHCI SD card controllers likely will
use a generic implementation in the MMC/SD layer for executing tuning,
which hasn't been written so far, though.
However, in fact this isn't a feature-only change; there are boards
based on Intel Bay Trail where DDR52 is problematic and the suggested
workaround is to use HS200 mode instead. So far exact details are
unknown, however, i. e. whether that's due to a defect in these SoCs
or on the boards.
Moreover, due to the above changes requiring to be aware of possible
MMC siblings in the fast path of mmc(4), corresponding information
now is cached in mmc_softc. As a side-effect, mmc_calculate_clock(),
mmc_delete_cards(), mmc_discover_cards() and mmc_rescan_cards() now
all are guaranteed to operate on the same set of devices as there no
longer is any use of device_get_children(9), which can fail in low
memory situations. Likewise, mmc_calculate_clock() now longer will
trigger a panic due to the latter.
o Fix a bug in the failure reporting of mmcsd_delete(); in case of an
error when the starting block of a previously stored erase request
is used (in order to be able to erase a full erase sector worth of
data), the starting block of the newly supplied bio_pblkno has to be
returned for indicating no progress. Otherwise, upper layers might
be told that a negative number of BIOs have been completed, leading
to a panic.
o Fix 2 bugs on resume:
- Things done in fork1(9) like the acquisition of an SX lock or the
sleepable memory allocation are incompatible with a MTX_DEF taken.
Thus, mmcsd_resume() must not call kproc_create(9), which in turn
uses fork1(9), with the disk_mtx (formerly part_mtx) held.
- In mmc_suspend(), the bus is powered down, which in the typical
case of a device being selected at the time of suspension, causes
the device deselection as part of the bus acquisition by mmc(4) in
mmc_scan() to fail as the bus isn't powered up again before later
in mmc_go_discovery(). Thus, power down with the bus acquired in
mmc_suspend(), which will trigger the deselection up-front.
o Fix a memory leak in mmcsd_ioctl() in case copyin(9) fails. [1]
o Fix missing variable initialization in mmc_switch_status(). [2]
o Fix R1_SWITCH_ERROR detection in mmc_switch_status(). [3]
o Handle the case of device_add_child(9) failing, for example due to
a memory shortage, gracefully in mmc(4) and sdhci(4), including not
leaking memory for the instance variables in case of mmc(4) (which
might or might not fix [4] as the latter problem has been discovered
independently).
o Handle the case of an unknown SD CSD version in mmc_decode_csd_sd()
gracefully instead of calling panic(9).
o Again, check and handle the return values of some additional function
calls in mmc(4) instead of assuming that everything went right or mark
non-fatal errors by casting the return value to void.
o Correct a typo in the Linux IOCTL compatibility; it should have been
MMC_IOC_MULTI_CMD rather than MMC_IOC_CMD_MULTI.
o Now that we are reaching ever faster speeds (more improvement in this
regard is to be expected when adding ADMA support to sdhci(4)), apply
a few micro-optimizations like predicting mmc(4) and sdhci(4) debugging
to be off or caching erase sector and maximum data sizes as well support
of block addressing in mmsd(4) (instead of doing 2 indirections on every
read/write request for determining the maximum data size for example).
Reported by: Coverity
CID: 1372612 [1], 1372624 [2], 1372594 [3], 1007069 [4]
2017-07-23 16:11:47 +00:00
|
|
|
struct callout retune_callout; /* Re-tuning mode 1 callout */
|
2012-10-16 01:10:43 +00:00
|
|
|
struct mmc_host host; /* Host parameters */
|
|
|
|
|
struct mmc_request *req; /* Current request */
|
|
|
|
|
struct mmc_command *curcmd; /* Current command of current request */
|
2017-01-29 00:05:49 +00:00
|
|
|
|
o Add support for eMMC HS200 and HS400 bus speed modes at 200 MHz to
sdhci(4), mmc(4) and mmcsd(4). For the most part, this consists of:
- Correcting and extending the infrastructure for negotiating and
enabling post-DDR52 modes already added as part of r315598. In
fact, HS400ES now should work as well but hasn't been activated
due to lack of corresponding hardware.
- Adding support executing standard SDHCI initial tuning as well
as re-tuning as required for eMMC HS200/HS400 and the fast UHS-I
SD card modes. Currently, corresponding methods are only hooked
up to the ACPI and PCI front-ends of sdhci(4), though. Moreover,
sdhci(4) won't offer any modes requiring (re-)tuning to the MMC/SD
layer in order to not break operations with other sdhci(4) front-
ends. Likewise, sdhci(4) now no longer offers modes requiring the
set_uhs_timing method introduced in r315598 to be implemented/
hooked up (previously, this method was used with DDR52 only, which
in turn is only available with Intel controllers so far, i. e. no
such limitation was necessary before). Similarly for 1.2/1.8 V VCCQ
support and the switch_vccq method.
- Addition of locking to the IOCTL half of mmcsd(4) to prevent races
with detachment and suspension, especially since it's required to
immediately switch away from RPMB partitions again after an access
to these (so re-tuning can take place anew, given that the current
eMMC specification v5.1 doesn't allow tuning commands to be issued
with a RPMB partition selected). Therefore, the existing part_mtx
lock in the mmcsd(4) softc is additionally renamed to disk_mtx in
order to denote that it only refers to the disk(9) half, likewise
for corresponding macros.
On the system where the addition of DDR52 support increased the read
throughput to ~80 MB/s (from ~45 MB/s at high speed), HS200 yields
~154 MB/s and HS400 ~187 MB/s, i. e. performance now has more than
quadrupled compared to pre-r315598.
Also, with the advent of (re-)tuning support, most infrastructure
necessary for SD card UHS-I modes up to SDR104 now is also in place.
Note, though, that the standard SDHCI way of (re-)tuning is special
in several ways, which also is why sending the actual tuning requests
to the device is part of sdhci(4). SDHCI implementations not following
the specification, MMC and non-SDHCI SD card controllers likely will
use a generic implementation in the MMC/SD layer for executing tuning,
which hasn't been written so far, though.
However, in fact this isn't a feature-only change; there are boards
based on Intel Bay Trail where DDR52 is problematic and the suggested
workaround is to use HS200 mode instead. So far exact details are
unknown, however, i. e. whether that's due to a defect in these SoCs
or on the boards.
Moreover, due to the above changes requiring to be aware of possible
MMC siblings in the fast path of mmc(4), corresponding information
now is cached in mmc_softc. As a side-effect, mmc_calculate_clock(),
mmc_delete_cards(), mmc_discover_cards() and mmc_rescan_cards() now
all are guaranteed to operate on the same set of devices as there no
longer is any use of device_get_children(9), which can fail in low
memory situations. Likewise, mmc_calculate_clock() now longer will
trigger a panic due to the latter.
o Fix a bug in the failure reporting of mmcsd_delete(); in case of an
error when the starting block of a previously stored erase request
is used (in order to be able to erase a full erase sector worth of
data), the starting block of the newly supplied bio_pblkno has to be
returned for indicating no progress. Otherwise, upper layers might
be told that a negative number of BIOs have been completed, leading
to a panic.
o Fix 2 bugs on resume:
- Things done in fork1(9) like the acquisition of an SX lock or the
sleepable memory allocation are incompatible with a MTX_DEF taken.
Thus, mmcsd_resume() must not call kproc_create(9), which in turn
uses fork1(9), with the disk_mtx (formerly part_mtx) held.
- In mmc_suspend(), the bus is powered down, which in the typical
case of a device being selected at the time of suspension, causes
the device deselection as part of the bus acquisition by mmc(4) in
mmc_scan() to fail as the bus isn't powered up again before later
in mmc_go_discovery(). Thus, power down with the bus acquired in
mmc_suspend(), which will trigger the deselection up-front.
o Fix a memory leak in mmcsd_ioctl() in case copyin(9) fails. [1]
o Fix missing variable initialization in mmc_switch_status(). [2]
o Fix R1_SWITCH_ERROR detection in mmc_switch_status(). [3]
o Handle the case of device_add_child(9) failing, for example due to
a memory shortage, gracefully in mmc(4) and sdhci(4), including not
leaking memory for the instance variables in case of mmc(4) (which
might or might not fix [4] as the latter problem has been discovered
independently).
o Handle the case of an unknown SD CSD version in mmc_decode_csd_sd()
gracefully instead of calling panic(9).
o Again, check and handle the return values of some additional function
calls in mmc(4) instead of assuming that everything went right or mark
non-fatal errors by casting the return value to void.
o Correct a typo in the Linux IOCTL compatibility; it should have been
MMC_IOC_MULTI_CMD rather than MMC_IOC_CMD_MULTI.
o Now that we are reaching ever faster speeds (more improvement in this
regard is to be expected when adding ADMA support to sdhci(4)), apply
a few micro-optimizations like predicting mmc(4) and sdhci(4) debugging
to be off or caching erase sector and maximum data sizes as well support
of block addressing in mmsd(4) (instead of doing 2 indirections on every
read/write request for determining the maximum data size for example).
Reported by: Coverity
CID: 1372612 [1], 1372624 [2], 1372594 [3], 1007069 [4]
2017-07-23 16:11:47 +00:00
|
|
|
struct mmc_request *tune_req; /* Tuning request */
|
|
|
|
|
struct mmc_command *tune_cmd; /* Tuning command of tuning request */
|
|
|
|
|
struct mmc_data *tune_data; /* Tuning data of tuning command */
|
|
|
|
|
uint32_t retune_ticks; /* Re-tuning callout ticks [hz] */
|
2012-10-16 01:10:43 +00:00
|
|
|
uint32_t intmask; /* Current interrupt mask */
|
|
|
|
|
uint32_t clock; /* Current clock freq. */
|
|
|
|
|
size_t offset; /* Data buffer offset */
|
|
|
|
|
uint8_t hostctrl; /* Current host control register */
|
o Add support for eMMC HS200 and HS400 bus speed modes at 200 MHz to
sdhci(4), mmc(4) and mmcsd(4). For the most part, this consists of:
- Correcting and extending the infrastructure for negotiating and
enabling post-DDR52 modes already added as part of r315598. In
fact, HS400ES now should work as well but hasn't been activated
due to lack of corresponding hardware.
- Adding support executing standard SDHCI initial tuning as well
as re-tuning as required for eMMC HS200/HS400 and the fast UHS-I
SD card modes. Currently, corresponding methods are only hooked
up to the ACPI and PCI front-ends of sdhci(4), though. Moreover,
sdhci(4) won't offer any modes requiring (re-)tuning to the MMC/SD
layer in order to not break operations with other sdhci(4) front-
ends. Likewise, sdhci(4) now no longer offers modes requiring the
set_uhs_timing method introduced in r315598 to be implemented/
hooked up (previously, this method was used with DDR52 only, which
in turn is only available with Intel controllers so far, i. e. no
such limitation was necessary before). Similarly for 1.2/1.8 V VCCQ
support and the switch_vccq method.
- Addition of locking to the IOCTL half of mmcsd(4) to prevent races
with detachment and suspension, especially since it's required to
immediately switch away from RPMB partitions again after an access
to these (so re-tuning can take place anew, given that the current
eMMC specification v5.1 doesn't allow tuning commands to be issued
with a RPMB partition selected). Therefore, the existing part_mtx
lock in the mmcsd(4) softc is additionally renamed to disk_mtx in
order to denote that it only refers to the disk(9) half, likewise
for corresponding macros.
On the system where the addition of DDR52 support increased the read
throughput to ~80 MB/s (from ~45 MB/s at high speed), HS200 yields
~154 MB/s and HS400 ~187 MB/s, i. e. performance now has more than
quadrupled compared to pre-r315598.
Also, with the advent of (re-)tuning support, most infrastructure
necessary for SD card UHS-I modes up to SDR104 now is also in place.
Note, though, that the standard SDHCI way of (re-)tuning is special
in several ways, which also is why sending the actual tuning requests
to the device is part of sdhci(4). SDHCI implementations not following
the specification, MMC and non-SDHCI SD card controllers likely will
use a generic implementation in the MMC/SD layer for executing tuning,
which hasn't been written so far, though.
However, in fact this isn't a feature-only change; there are boards
based on Intel Bay Trail where DDR52 is problematic and the suggested
workaround is to use HS200 mode instead. So far exact details are
unknown, however, i. e. whether that's due to a defect in these SoCs
or on the boards.
Moreover, due to the above changes requiring to be aware of possible
MMC siblings in the fast path of mmc(4), corresponding information
now is cached in mmc_softc. As a side-effect, mmc_calculate_clock(),
mmc_delete_cards(), mmc_discover_cards() and mmc_rescan_cards() now
all are guaranteed to operate on the same set of devices as there no
longer is any use of device_get_children(9), which can fail in low
memory situations. Likewise, mmc_calculate_clock() now longer will
trigger a panic due to the latter.
o Fix a bug in the failure reporting of mmcsd_delete(); in case of an
error when the starting block of a previously stored erase request
is used (in order to be able to erase a full erase sector worth of
data), the starting block of the newly supplied bio_pblkno has to be
returned for indicating no progress. Otherwise, upper layers might
be told that a negative number of BIOs have been completed, leading
to a panic.
o Fix 2 bugs on resume:
- Things done in fork1(9) like the acquisition of an SX lock or the
sleepable memory allocation are incompatible with a MTX_DEF taken.
Thus, mmcsd_resume() must not call kproc_create(9), which in turn
uses fork1(9), with the disk_mtx (formerly part_mtx) held.
- In mmc_suspend(), the bus is powered down, which in the typical
case of a device being selected at the time of suspension, causes
the device deselection as part of the bus acquisition by mmc(4) in
mmc_scan() to fail as the bus isn't powered up again before later
in mmc_go_discovery(). Thus, power down with the bus acquired in
mmc_suspend(), which will trigger the deselection up-front.
o Fix a memory leak in mmcsd_ioctl() in case copyin(9) fails. [1]
o Fix missing variable initialization in mmc_switch_status(). [2]
o Fix R1_SWITCH_ERROR detection in mmc_switch_status(). [3]
o Handle the case of device_add_child(9) failing, for example due to
a memory shortage, gracefully in mmc(4) and sdhci(4), including not
leaking memory for the instance variables in case of mmc(4) (which
might or might not fix [4] as the latter problem has been discovered
independently).
o Handle the case of an unknown SD CSD version in mmc_decode_csd_sd()
gracefully instead of calling panic(9).
o Again, check and handle the return values of some additional function
calls in mmc(4) instead of assuming that everything went right or mark
non-fatal errors by casting the return value to void.
o Correct a typo in the Linux IOCTL compatibility; it should have been
MMC_IOC_MULTI_CMD rather than MMC_IOC_CMD_MULTI.
o Now that we are reaching ever faster speeds (more improvement in this
regard is to be expected when adding ADMA support to sdhci(4)), apply
a few micro-optimizations like predicting mmc(4) and sdhci(4) debugging
to be off or caching erase sector and maximum data sizes as well support
of block addressing in mmsd(4) (instead of doing 2 indirections on every
read/write request for determining the maximum data size for example).
Reported by: Coverity
CID: 1372612 [1], 1372624 [2], 1372594 [3], 1007069 [4]
2017-07-23 16:11:47 +00:00
|
|
|
uint8_t retune_count; /* Controller re-tuning count [s] */
|
|
|
|
|
uint8_t retune_mode; /* Controller re-tuning mode */
|
|
|
|
|
#define SDHCI_RETUNE_MODE_1 0x00
|
|
|
|
|
#define SDHCI_RETUNE_MODE_2 0x01
|
|
|
|
|
#define SDHCI_RETUNE_MODE_3 0x02
|
|
|
|
|
uint8_t retune_req; /* Re-tuning request status */
|
|
|
|
|
#define SDHCI_RETUNE_REQ_NEEDED 0x01 /* Re-tuning w/o circuit reset needed */
|
|
|
|
|
#define SDHCI_RETUNE_REQ_RESET 0x02 /* Re-tuning w/ circuit reset needed */
|
2012-10-16 01:10:43 +00:00
|
|
|
u_char power; /* Current power */
|
|
|
|
|
u_char bus_busy; /* Bus busy status */
|
|
|
|
|
u_char cmd_done; /* CMD command part done flag */
|
|
|
|
|
u_char data_done; /* DAT command part done flag */
|
|
|
|
|
u_char flags; /* Request execution flags */
|
2017-02-04 19:35:38 +00:00
|
|
|
#define CMD_STARTED 1
|
|
|
|
|
#define STOP_STARTED 2
|
|
|
|
|
#define SDHCI_USE_DMA 4 /* Use DMA for this req. */
|
|
|
|
|
#define PLATFORM_DATA_STARTED 8 /* Data xfer is handled by platform */
|
2017-07-09 16:57:24 +00:00
|
|
|
|
2017-07-10 03:38:17 +00:00
|
|
|
#ifdef MMCCAM
|
2017-07-09 16:57:24 +00:00
|
|
|
/* CAM stuff */
|
|
|
|
|
union ccb *ccb;
|
|
|
|
|
struct cam_devq *devq;
|
|
|
|
|
struct cam_sim *sim;
|
|
|
|
|
struct mtx sim_mtx;
|
|
|
|
|
u_char card_present; /* XXX Maybe derive this from elsewhere? */
|
2017-07-10 03:38:17 +00:00
|
|
|
#endif
|
2012-10-16 01:10:43 +00:00
|
|
|
};
|
|
|
|
|
|
2017-01-29 00:05:49 +00:00
|
|
|
int sdhci_generic_read_ivar(device_t bus, device_t child, int which,
|
|
|
|
|
uintptr_t *result);
|
|
|
|
|
int sdhci_generic_write_ivar(device_t bus, device_t child, int which,
|
|
|
|
|
uintptr_t value);
|
2012-10-16 01:10:43 +00:00
|
|
|
int sdhci_init_slot(device_t dev, struct sdhci_slot *slot, int num);
|
|
|
|
|
void sdhci_start_slot(struct sdhci_slot *slot);
|
2013-02-28 19:43:14 +00:00
|
|
|
/* performs generic clean-up for platform transfers */
|
|
|
|
|
void sdhci_finish_data(struct sdhci_slot *slot);
|
2012-10-16 01:10:43 +00:00
|
|
|
int sdhci_cleanup_slot(struct sdhci_slot *slot);
|
|
|
|
|
int sdhci_generic_suspend(struct sdhci_slot *slot);
|
|
|
|
|
int sdhci_generic_resume(struct sdhci_slot *slot);
|
|
|
|
|
int sdhci_generic_update_ios(device_t brdev, device_t reqdev);
|
o Add support for eMMC HS200 and HS400 bus speed modes at 200 MHz to
sdhci(4), mmc(4) and mmcsd(4). For the most part, this consists of:
- Correcting and extending the infrastructure for negotiating and
enabling post-DDR52 modes already added as part of r315598. In
fact, HS400ES now should work as well but hasn't been activated
due to lack of corresponding hardware.
- Adding support executing standard SDHCI initial tuning as well
as re-tuning as required for eMMC HS200/HS400 and the fast UHS-I
SD card modes. Currently, corresponding methods are only hooked
up to the ACPI and PCI front-ends of sdhci(4), though. Moreover,
sdhci(4) won't offer any modes requiring (re-)tuning to the MMC/SD
layer in order to not break operations with other sdhci(4) front-
ends. Likewise, sdhci(4) now no longer offers modes requiring the
set_uhs_timing method introduced in r315598 to be implemented/
hooked up (previously, this method was used with DDR52 only, which
in turn is only available with Intel controllers so far, i. e. no
such limitation was necessary before). Similarly for 1.2/1.8 V VCCQ
support and the switch_vccq method.
- Addition of locking to the IOCTL half of mmcsd(4) to prevent races
with detachment and suspension, especially since it's required to
immediately switch away from RPMB partitions again after an access
to these (so re-tuning can take place anew, given that the current
eMMC specification v5.1 doesn't allow tuning commands to be issued
with a RPMB partition selected). Therefore, the existing part_mtx
lock in the mmcsd(4) softc is additionally renamed to disk_mtx in
order to denote that it only refers to the disk(9) half, likewise
for corresponding macros.
On the system where the addition of DDR52 support increased the read
throughput to ~80 MB/s (from ~45 MB/s at high speed), HS200 yields
~154 MB/s and HS400 ~187 MB/s, i. e. performance now has more than
quadrupled compared to pre-r315598.
Also, with the advent of (re-)tuning support, most infrastructure
necessary for SD card UHS-I modes up to SDR104 now is also in place.
Note, though, that the standard SDHCI way of (re-)tuning is special
in several ways, which also is why sending the actual tuning requests
to the device is part of sdhci(4). SDHCI implementations not following
the specification, MMC and non-SDHCI SD card controllers likely will
use a generic implementation in the MMC/SD layer for executing tuning,
which hasn't been written so far, though.
However, in fact this isn't a feature-only change; there are boards
based on Intel Bay Trail where DDR52 is problematic and the suggested
workaround is to use HS200 mode instead. So far exact details are
unknown, however, i. e. whether that's due to a defect in these SoCs
or on the boards.
Moreover, due to the above changes requiring to be aware of possible
MMC siblings in the fast path of mmc(4), corresponding information
now is cached in mmc_softc. As a side-effect, mmc_calculate_clock(),
mmc_delete_cards(), mmc_discover_cards() and mmc_rescan_cards() now
all are guaranteed to operate on the same set of devices as there no
longer is any use of device_get_children(9), which can fail in low
memory situations. Likewise, mmc_calculate_clock() now longer will
trigger a panic due to the latter.
o Fix a bug in the failure reporting of mmcsd_delete(); in case of an
error when the starting block of a previously stored erase request
is used (in order to be able to erase a full erase sector worth of
data), the starting block of the newly supplied bio_pblkno has to be
returned for indicating no progress. Otherwise, upper layers might
be told that a negative number of BIOs have been completed, leading
to a panic.
o Fix 2 bugs on resume:
- Things done in fork1(9) like the acquisition of an SX lock or the
sleepable memory allocation are incompatible with a MTX_DEF taken.
Thus, mmcsd_resume() must not call kproc_create(9), which in turn
uses fork1(9), with the disk_mtx (formerly part_mtx) held.
- In mmc_suspend(), the bus is powered down, which in the typical
case of a device being selected at the time of suspension, causes
the device deselection as part of the bus acquisition by mmc(4) in
mmc_scan() to fail as the bus isn't powered up again before later
in mmc_go_discovery(). Thus, power down with the bus acquired in
mmc_suspend(), which will trigger the deselection up-front.
o Fix a memory leak in mmcsd_ioctl() in case copyin(9) fails. [1]
o Fix missing variable initialization in mmc_switch_status(). [2]
o Fix R1_SWITCH_ERROR detection in mmc_switch_status(). [3]
o Handle the case of device_add_child(9) failing, for example due to
a memory shortage, gracefully in mmc(4) and sdhci(4), including not
leaking memory for the instance variables in case of mmc(4) (which
might or might not fix [4] as the latter problem has been discovered
independently).
o Handle the case of an unknown SD CSD version in mmc_decode_csd_sd()
gracefully instead of calling panic(9).
o Again, check and handle the return values of some additional function
calls in mmc(4) instead of assuming that everything went right or mark
non-fatal errors by casting the return value to void.
o Correct a typo in the Linux IOCTL compatibility; it should have been
MMC_IOC_MULTI_CMD rather than MMC_IOC_CMD_MULTI.
o Now that we are reaching ever faster speeds (more improvement in this
regard is to be expected when adding ADMA support to sdhci(4)), apply
a few micro-optimizations like predicting mmc(4) and sdhci(4) debugging
to be off or caching erase sector and maximum data sizes as well support
of block addressing in mmsd(4) (instead of doing 2 indirections on every
read/write request for determining the maximum data size for example).
Reported by: Coverity
CID: 1372612 [1], 1372624 [2], 1372594 [3], 1007069 [4]
2017-07-23 16:11:47 +00:00
|
|
|
int sdhci_generic_tune(device_t brdev, device_t reqdev, bool hs400);
|
o Add support for eMMC DDR bus speed mode at 52 MHz to sdhci(4) and
mmc(4). For the most part, this consists of support for:
- Switching the signal voltage (VCCQ) to 1.8 V or (if supported
by the host controller) to 1.2 V,
- setting the UHS mode as appropriate in the SDHCI_HOST_CONTROL2
register,
- setting the power class in the eMMC device according to the
core supply voltage (VCC),
- using different bits for enabling a bus width of 4 and 8 bits
in the the eMMC device at DDR or higher timings respectively,
- arbitrating timings faster than high speed if there actually
are additional devices on the same MMC bus.
Given that support for DDR52 is not denoted by SDHCI capability
registers, availability of that timing is indicated by a new
quirk SDHCI_QUIRK_MMC_DDR52 and only enabled for Intel SDHCI
controllers so far. Generally, what it takes for a sdhci(4)
front-end to enable support for DDR52 is to hook up the bridge
method mmcbr_switch_vccq (which especially for 1.2 V signaling
support is chip/board specific) and the sdhci_set_uhs_timing
sdhci(4) method.
As a side-effect, this change also fixes communication with
some eMMC devices at SDR high speed mode with 52 MHz due to
the signaling voltage and UHS bits in the SDHCI controller no
longer being left in an inappropriate state.
Compared to 52 MHz at SDR high speed which typically yields
~45 MB/s with the eMMC chips tested, throughput goes up to
~80 MB/s at DDR52.
Additionally, this change already adds infrastructure and quite
some code for modes up to HS400ES and SDR104 respectively (I did
not want to add to much stuff at a time, though). Essentially,
what is still missing in order to be able to activate support
for these latter is is support for and handling of (re-)tuning.
o In sdhci(4), add two tunables hw.sdhci.quirk_clear as well as
hw.sdhci.quirk_set, which (when hooked up in the front-end)
allow to set/clear sdhci(4) quirks for debugging and testing
purposes. However, especially for SDHCI controllers on the
PCI bus which have no specific support code so far and, thus,
are picked up as generic SDHCI controllers, hw.sdhci.quirk_set
allows for setting the necessary quirks (if required).
o In mmc(4), check and handle the return values of some more
function calls instead of assuming that everything went right.
In case failures actually are not problematic, indicate that
by casting the return value to void.
Reviewed by: jmcneill
2017-03-19 23:27:17 +00:00
|
|
|
int sdhci_generic_switch_vccq(device_t brdev, device_t reqdev);
|
o Add support for eMMC HS200 and HS400 bus speed modes at 200 MHz to
sdhci(4), mmc(4) and mmcsd(4). For the most part, this consists of:
- Correcting and extending the infrastructure for negotiating and
enabling post-DDR52 modes already added as part of r315598. In
fact, HS400ES now should work as well but hasn't been activated
due to lack of corresponding hardware.
- Adding support executing standard SDHCI initial tuning as well
as re-tuning as required for eMMC HS200/HS400 and the fast UHS-I
SD card modes. Currently, corresponding methods are only hooked
up to the ACPI and PCI front-ends of sdhci(4), though. Moreover,
sdhci(4) won't offer any modes requiring (re-)tuning to the MMC/SD
layer in order to not break operations with other sdhci(4) front-
ends. Likewise, sdhci(4) now no longer offers modes requiring the
set_uhs_timing method introduced in r315598 to be implemented/
hooked up (previously, this method was used with DDR52 only, which
in turn is only available with Intel controllers so far, i. e. no
such limitation was necessary before). Similarly for 1.2/1.8 V VCCQ
support and the switch_vccq method.
- Addition of locking to the IOCTL half of mmcsd(4) to prevent races
with detachment and suspension, especially since it's required to
immediately switch away from RPMB partitions again after an access
to these (so re-tuning can take place anew, given that the current
eMMC specification v5.1 doesn't allow tuning commands to be issued
with a RPMB partition selected). Therefore, the existing part_mtx
lock in the mmcsd(4) softc is additionally renamed to disk_mtx in
order to denote that it only refers to the disk(9) half, likewise
for corresponding macros.
On the system where the addition of DDR52 support increased the read
throughput to ~80 MB/s (from ~45 MB/s at high speed), HS200 yields
~154 MB/s and HS400 ~187 MB/s, i. e. performance now has more than
quadrupled compared to pre-r315598.
Also, with the advent of (re-)tuning support, most infrastructure
necessary for SD card UHS-I modes up to SDR104 now is also in place.
Note, though, that the standard SDHCI way of (re-)tuning is special
in several ways, which also is why sending the actual tuning requests
to the device is part of sdhci(4). SDHCI implementations not following
the specification, MMC and non-SDHCI SD card controllers likely will
use a generic implementation in the MMC/SD layer for executing tuning,
which hasn't been written so far, though.
However, in fact this isn't a feature-only change; there are boards
based on Intel Bay Trail where DDR52 is problematic and the suggested
workaround is to use HS200 mode instead. So far exact details are
unknown, however, i. e. whether that's due to a defect in these SoCs
or on the boards.
Moreover, due to the above changes requiring to be aware of possible
MMC siblings in the fast path of mmc(4), corresponding information
now is cached in mmc_softc. As a side-effect, mmc_calculate_clock(),
mmc_delete_cards(), mmc_discover_cards() and mmc_rescan_cards() now
all are guaranteed to operate on the same set of devices as there no
longer is any use of device_get_children(9), which can fail in low
memory situations. Likewise, mmc_calculate_clock() now longer will
trigger a panic due to the latter.
o Fix a bug in the failure reporting of mmcsd_delete(); in case of an
error when the starting block of a previously stored erase request
is used (in order to be able to erase a full erase sector worth of
data), the starting block of the newly supplied bio_pblkno has to be
returned for indicating no progress. Otherwise, upper layers might
be told that a negative number of BIOs have been completed, leading
to a panic.
o Fix 2 bugs on resume:
- Things done in fork1(9) like the acquisition of an SX lock or the
sleepable memory allocation are incompatible with a MTX_DEF taken.
Thus, mmcsd_resume() must not call kproc_create(9), which in turn
uses fork1(9), with the disk_mtx (formerly part_mtx) held.
- In mmc_suspend(), the bus is powered down, which in the typical
case of a device being selected at the time of suspension, causes
the device deselection as part of the bus acquisition by mmc(4) in
mmc_scan() to fail as the bus isn't powered up again before later
in mmc_go_discovery(). Thus, power down with the bus acquired in
mmc_suspend(), which will trigger the deselection up-front.
o Fix a memory leak in mmcsd_ioctl() in case copyin(9) fails. [1]
o Fix missing variable initialization in mmc_switch_status(). [2]
o Fix R1_SWITCH_ERROR detection in mmc_switch_status(). [3]
o Handle the case of device_add_child(9) failing, for example due to
a memory shortage, gracefully in mmc(4) and sdhci(4), including not
leaking memory for the instance variables in case of mmc(4) (which
might or might not fix [4] as the latter problem has been discovered
independently).
o Handle the case of an unknown SD CSD version in mmc_decode_csd_sd()
gracefully instead of calling panic(9).
o Again, check and handle the return values of some additional function
calls in mmc(4) instead of assuming that everything went right or mark
non-fatal errors by casting the return value to void.
o Correct a typo in the Linux IOCTL compatibility; it should have been
MMC_IOC_MULTI_CMD rather than MMC_IOC_CMD_MULTI.
o Now that we are reaching ever faster speeds (more improvement in this
regard is to be expected when adding ADMA support to sdhci(4)), apply
a few micro-optimizations like predicting mmc(4) and sdhci(4) debugging
to be off or caching erase sector and maximum data sizes as well support
of block addressing in mmsd(4) (instead of doing 2 indirections on every
read/write request for determining the maximum data size for example).
Reported by: Coverity
CID: 1372612 [1], 1372624 [2], 1372594 [3], 1007069 [4]
2017-07-23 16:11:47 +00:00
|
|
|
int sdhci_generic_retune(device_t brdev, device_t reqdev, bool reset);
|
2017-01-29 00:05:49 +00:00
|
|
|
int sdhci_generic_request(device_t brdev, device_t reqdev,
|
|
|
|
|
struct mmc_request *req);
|
2012-10-16 01:10:43 +00:00
|
|
|
int sdhci_generic_get_ro(device_t brdev, device_t reqdev);
|
|
|
|
|
int sdhci_generic_acquire_host(device_t brdev, device_t reqdev);
|
|
|
|
|
int sdhci_generic_release_host(device_t brdev, device_t reqdev);
|
|
|
|
|
void sdhci_generic_intr(struct sdhci_slot *slot);
|
2013-02-16 23:12:06 +00:00
|
|
|
uint32_t sdhci_generic_min_freq(device_t brdev, struct sdhci_slot *slot);
|
2017-01-08 02:32:53 +00:00
|
|
|
bool sdhci_generic_get_card_present(device_t brdev, struct sdhci_slot *slot);
|
o Add support for eMMC DDR bus speed mode at 52 MHz to sdhci(4) and
mmc(4). For the most part, this consists of support for:
- Switching the signal voltage (VCCQ) to 1.8 V or (if supported
by the host controller) to 1.2 V,
- setting the UHS mode as appropriate in the SDHCI_HOST_CONTROL2
register,
- setting the power class in the eMMC device according to the
core supply voltage (VCC),
- using different bits for enabling a bus width of 4 and 8 bits
in the the eMMC device at DDR or higher timings respectively,
- arbitrating timings faster than high speed if there actually
are additional devices on the same MMC bus.
Given that support for DDR52 is not denoted by SDHCI capability
registers, availability of that timing is indicated by a new
quirk SDHCI_QUIRK_MMC_DDR52 and only enabled for Intel SDHCI
controllers so far. Generally, what it takes for a sdhci(4)
front-end to enable support for DDR52 is to hook up the bridge
method mmcbr_switch_vccq (which especially for 1.2 V signaling
support is chip/board specific) and the sdhci_set_uhs_timing
sdhci(4) method.
As a side-effect, this change also fixes communication with
some eMMC devices at SDR high speed mode with 52 MHz due to
the signaling voltage and UHS bits in the SDHCI controller no
longer being left in an inappropriate state.
Compared to 52 MHz at SDR high speed which typically yields
~45 MB/s with the eMMC chips tested, throughput goes up to
~80 MB/s at DDR52.
Additionally, this change already adds infrastructure and quite
some code for modes up to HS400ES and SDR104 respectively (I did
not want to add to much stuff at a time, though). Essentially,
what is still missing in order to be able to activate support
for these latter is is support for and handling of (re-)tuning.
o In sdhci(4), add two tunables hw.sdhci.quirk_clear as well as
hw.sdhci.quirk_set, which (when hooked up in the front-end)
allow to set/clear sdhci(4) quirks for debugging and testing
purposes. However, especially for SDHCI controllers on the
PCI bus which have no specific support code so far and, thus,
are picked up as generic SDHCI controllers, hw.sdhci.quirk_set
allows for setting the necessary quirks (if required).
o In mmc(4), check and handle the return values of some more
function calls instead of assuming that everything went right.
In case failures actually are not problematic, indicate that
by casting the return value to void.
Reviewed by: jmcneill
2017-03-19 23:27:17 +00:00
|
|
|
void sdhci_generic_set_uhs_timing(device_t brdev, struct sdhci_slot *slot);
|
2017-01-09 01:15:18 +00:00
|
|
|
void sdhci_handle_card_present(struct sdhci_slot *slot, bool is_present);
|
2012-10-16 01:10:43 +00:00
|
|
|
|
|
|
|
|
#endif /* __SDHCI_H__ */
|
