o Don't allocate resources for SDMA in sdhci(4) if the controller or the
  front-end doesn't support SDMA or the latter implements a platform-
  specific transfer method instead. While at it, factor out allocation
  and freeing of SDMA resources to sdhci_dma_{alloc,free}() in order to
  keep the code more readable when adding support for ADMA variants.

o Base the size of the SDMA bounce buffer on MAXPHYS up to the maximum
  of 512 KiB instead of using a fixed 4-KiB-buffer. With the default
  MAXPHYS of 128 KiB and depending on the controller and medium, this
  reduces the number of SDHCI interrupts by a factor of ~16 to ~32 on
  sequential reads while an increase of throughput of up to ~84 % was
  seen.

  Front-ends for broken controllers that only support an SDMA buffer
  boundary of a specific size may set SDHCI_QUIRK_BROKEN_SDMA_BOUNDARY
  and supply a size via struct sdhci_slot. According to Linux, only -
  unsupported in stable/10 anyway - Qualcomm MSM-type SDHCI controllers
  are affected by this, though.

  Requested by: Shreyank Amartya (unconditional bump to 512 KiB)

o Introduce a SDHCI_DEPEND macro for specifying the dependency of the
  front-end modules on the sdhci(4) one and bump the module version
  of sdhci(4) to 2 via an also newly introduced SDHCI_VERSION in order
  to ensure that all components are in sync WRT struct sdhci_slot.

o In sdhci(4):
  - Make pointers const were applicable, and
  - replace a few device_printf(9) calls with slot_printf() for
    consistency.

- Add ACPI identifier for AMD eMMC 5.0 controller [1]
- Add a quirk handling for AMDI0040 controllers allowing them to do HS400. [2]

Submitted by:	Rajesh Kumar [1], Shreyank Amartya (original version) [2]

The broken DDR52 support of Intel Bay Trail eMMC controllers rumored
in the commit log of r321385 has been confirmed via the public VLI54
erratum. Thus, stop advertising DDR52 for these controllers.
Note that this change should hardly make a difference in practice as
eMMC chips from the same era as these SoCs most likely support HS200
at least, probably even up to HS400ES.

- According to section 2.2.5 of the SDHCI specification version 4.20,
  SDHCI_TRNS_ACMD12 is to be set only for multiple-block read/write
  commands without data length information, so don't unconditionally
  set this bit. The result matches what e. g. Linux does.
- Section 2.2.19 of the SDHCI specification version 4.20 states that
  SDHCI_ACMD12_ERR should be only valid if SDHCI_INT_ACMD12ERR is set
  and hardware may clear SDHCI_ACMD12_ERR when SDHCI_INT_ACMD12ERR is
  cleared (differing silicon behavior is specifically allowed, though).
  Thus, read SDHCI_ACMD12_ERR before clearing SDHCI_INT_ACMD12ERR.
  While at it, use the 16-bit accessor rather than the 32-bit one for
  reading the 16-bit SDHCI_ACMD12_ERR.
- SDHCI_INT_TUNEERR isn't one of the ROC bits in SDHCI_INT_STATUS so
  clear it explicitly.
- Add missing prototypes and sort them.
- Explicitly compare a pointer to NULL. The __builtin_expect() of clang
  3.4.1 otherwise isn't able to cope with the expression.

- There is no need to keep the tuning error and re-tuning interrupts
  enabled (though, no interrupt generation enabled for them) all the
  time as soon as (re-)tuning is supported; only enable them and let
  them generate interrupts when actually using (re-)tuning.
- Also disable all interrupts except SDHCI_INT_DATA_AVAIL ones while
  executing tuning and not just their signaling.
- Set the tuning error and re-tuning interrupt enable bits based on
  the SDHCI_TUNING_ENABLED rather than the SDHCI_TUNING_SUPPORTED flag,
  i. e. only when (re-)tuning is actually used. Currently, this change
  makes no net difference, though.

Add quirks for Intel Denverton eMMC 5.0 controllers.

- Check the slot type capability, set SDHCI_SLOT_{EMBEDDED,NON_REMOVABLE}
  for embedded slots. Fail in the sdhci(4) initialization for slot type
  shared, which is completely unsupported by this driver at the moment. [1]
  For Intel eMMC controllers, taking the embedded slot type into account
  obsoltes setting SDHCI_QUIRK_ALL_SLOTS_NON_REMOVABLE so remove these quirk
  entries.
- Hide the 1.8 V VDD capability when the slot is detected as non-embedded,
  as the SDHCI specification explicitly states that 1.8 V VDD is applicable
  to embedded slots only. [2]
- Define some easy bits of the SDHCI specification v4.20. [3]
- Don't leak bus_dma(9) resources in failure paths of sdhci_init_slot().

Obtained from:	DragonFlyBSD 65704a46 [1], 7ba10b88 [2], 0df14648 [3]

o Use SDHCI_CAN_DRIVE_TYPE_{A,C,D} to check for driver type support in
  SDHCI_CAPABILITIES2 instead of SDHCI_CTRL2_DRIVER_TYPE_{A,C,D} which
  are meant for setting the driver type in SDHCI_HOST_CONTROL2.

o Correct a typo in the comment part of r320577 (MFCed to stable/10 in
  r320899).

o Add support for eMMC HS200 and HS400 bus speed modes at 200 MHz to
  sdhci(4), mmc(4) and mmcsd(4).

  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 (pre-r318495 in stable/10).

  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(),
  now longer will trigger a panic in low memory situations and all of
  mmc(4) operate on the same set of child devices.

o Fix a bug in the failure reporting of mmcsd_delete() that could lead
  to a panic.

o Fix 2 bugs on resume, one in mmcsd(4) that could lead to a panic and
  another one in mmc(4) that could lead to devices no longer working.

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), also
  fixing [4].

o Correctly use the size of a pointer rather than that of a pointer to
  a pointer (this bug was present in head r321385 only, i. e. not in a
  stable branch). [5]

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 to mmc(4), mmcsd(4) and sdhci(4).

o Correct confusing and error prone mix-ups between "br" or "bridge" in
  mmc(4) and mmcsd(4) where - according to the terminology outlined in
  comments of bridge.h and mmcbr_if.m around since their addition in
  r163516 - the bus is meant and used instead.

o Remove comment lines from bridge.h incorrectly suggesting that there
  would be a MMC bridge base class driver.

o Update comments in bridge.h regarding the star topology of SD and SDIO;
  since version 3.00 of the SDHCI specification, for eSD and eSDIO bus
  topologies are actually possible in form of so called "shared buses"
  (in some subcontext later on renamed to "embedded" buses).

Reported by:	Coverity
CID:		1372612 [1], 1372624 [2], 1372594 [3], 1007069 [4],
		1378432 [5]

Retry up to 2 ms to enable bus power as at least with some Intel
SDHCI/eMMC controllers the first attempt after a D3 to D0 transition,
i. e. when the firmware has put the devices into D3 state before,
can fail.

- Unlike as in the PCI case, when attached to ACPI, Intel Bay Trail
  and Braswell eMMC and SDXC controllers share the same IDs. Like in
  the PCI case, Braswell eMMC needs the SDHCI_QUIRK_DATA_TIMEOUT_1MHZ
  quirk (see r311794 for the corresponding change to the sdhci(4) PCI
  PCI front-end), though. However, due to the shared ACPI IDs, this
  is trickier to do.
- Intel Apollo Lake eMMC and SDXC controllers are affected by the
  APL18 ("Using 32-bit Addressing Mode With SD/eMMC Controller May
  Lead to Unpredictable System Behavior") silicon bug. When this
  erratum hits, typically both SDHCI and XHCI controllers wedge.
  According to Intel, using ADMA2 with 64-bit addressing and 96-bit
  descriptors serves as a workaround. Until such times when sdhci(4)
  has ADMA2 support, flag DMA as broken for affected interfaces.
  This turns out to work around the problem, too, at the cost of
  performance.
- In the sdhci(4) ACPI front-end, probe the Intel Apollo Lake eMMC
  and SDXC controllers, too.