]> CyberLeo.Net >> Repos - FreeBSD/stable/10.git/commit
MFC: r318282
authormarius <marius@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f>
Thu, 18 May 2017 21:00:53 +0000 (21:00 +0000)
committermarius <marius@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f>
Thu, 18 May 2017 21:00:53 +0000 (21:00 +0000)
commite0d2ce82b5ac8acd8f7aec35075a6db2cf323109
tree180b7781dde20d26906cf34c9d45618613be0794
parentdd6e977d522c5c2e7b91b5c15bc220cb208b77b1
MFC: r318282

- 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.

git-svn-id: svn://svn.freebsd.org/base/stable/10@318497 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
sys/dev/sdhci/sdhci_acpi.c
sys/dev/sdhci/sdhci_pci.c