1. 27 Sep, 2019 5 commits
    • Ben Chuang's avatar
      mmc: host: sdhci-pci: Add Genesys Logic GL975x support · e51df6ce
      Ben Chuang authored
      
      
      Add support for the GL9750 and GL9755 chipsets.
      
      Enable v4 mode and wait 5ms after set 1.8V signal enable for GL9750/
      GL9755. Fix the value of SDHCI_MAX_CURRENT register and use the vendor
      tuning flow for GL9750.
      
      Co-developed-by: default avatarMichael K Johnson <johnsonm@danlj.org>
      Signed-off-by: default avatarMichael K Johnson <johnsonm@danlj.org>
      Signed-off-by: default avatarBen Chuang <ben.chuang@genesyslogic.com.tw>
      Acked-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      e51df6ce
    • Nicolin Chen's avatar
      mmc: tegra: Implement ->set_dma_mask() · b960bc44
      Nicolin Chen authored
      The SDHCI controller on Tegra186 supports 40-bit addressing, which is
      usually enough to address all of system memory. However, if the SDHCI
      controller is behind an IOMMU, the address space can go beyond. This
      happens on Tegra186 and later where the ARM SMMU has an input address
      space of 48 bits. If the DMA API is backed by this ARM SMMU, the top-
      down IOVA allocator will cause IOV addresses to be returned that the
      SDHCI controller cannot access.
      
      Unfortunately, prior to the introduction of the ->set_dma_mask() host
      operation, the SDHCI core would set either a 64-bit DMA mask if the
      controller claimed to support 64-bit addressing, or a 32-bit DMA mask
      otherwise.
      
      Since the full 64 bits cannot be addressed on Tegra, this had to be
      worked around in commit 68481a7e
      
       ("mmc: tegra: Mark 64 bit dma
      broken on Tegra186") by setting the SDHCI_QUIRK2_BROKEN_64_BIT_DMA
      quirk, which effectively restricts the DMA mask to 32 bits.
      
      One disadvantage of this is that dma_map_*() APIs will now try to use
      the swiotlb to bounce DMA to addresses beyond of the controller's DMA
      mask. This in turn caused degraded performance and can lead to
      situations where the swiotlb buffer is exhausted, which in turn leads
      to DMA transfers to fail.
      
      With the recent introduction of the ->set_dma_mask() host operation,
      this can now be properly fixed. For each generation of Tegra, the exact
      supported DMA mask can be configured. This kills two birds with one
      stone: it avoids the use of bounce buffers because system memory never
      exceeds the addressable memory range of the SDHCI controllers on these
      devices, and at the same time when an IOMMU is involved, it prevents
      IOV addresses from being allocated beyond the addressible range of the
      controllers.
      
      Since the DMA mask is now properly handled, the 64-bit DMA quirk can be
      removed.
      
      Signed-off-by: default avatarNicolin Chen <nicoleotsuka@gmail.com>
      [treding@nvidia.com: provide more background in commit message]
      Tested-by: default avatarNicolin Chen <nicoleotsuka@gmail.com>
      Acked-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      Cc: stable@vger.kernel.org # v4.15 +
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      b960bc44
    • Adrian Hunter's avatar
      mmc: sdhci: Let drivers define their DMA mask · 4ee7dde4
      Adrian Hunter authored
      
      
      Add host operation ->set_dma_mask() so that drivers can define their own
      DMA masks.
      
      Signed-off-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Tested-by: default avatarNicolin Chen <nicoleotsuka@gmail.com>
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      Cc: stable@vger.kernel.org # v4.15 +
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      4ee7dde4
    • Russell King's avatar
      mmc: sdhci-of-esdhc: set DMA snooping based on DMA coherence · 121bd08b
      Russell King authored
      
      
      We must not unconditionally set the DMA snoop bit; if the DMA API is
      assuming that the device is not DMA coherent, and the device snoops the
      CPU caches, the device can see stale cache lines brought in by
      speculative prefetch.
      
      This leads to the device seeing stale data, potentially resulting in
      corrupted data transfers.  Commonly, this results in a descriptor fetch
      error such as:
      
      mmc0: ADMA error
      mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
      mmc0: sdhci: Sys addr:  0x00000000 | Version:  0x00002202
      mmc0: sdhci: Blk size:  0x00000008 | Blk cnt:  0x00000001
      mmc0: sdhci: Argument:  0x00000000 | Trn mode: 0x00000013
      mmc0: sdhci: Present:   0x01f50008 | Host ctl: 0x00000038
      mmc0: sdhci: Power:     0x00000003 | Blk gap:  0x00000000
      mmc0: sdhci: Wake-up:   0x00000000 | Clock:    0x000040d8
      mmc0: sdhci: Timeout:   0x00000003 | Int stat: 0x00000001
      mmc0: sdhci: Int enab:  0x037f108f | Sig enab: 0x037f108b
      mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00002202
      mmc0: sdhci: Caps:      0x35fa0000 | Caps_1:   0x0000af00
      mmc0: sdhci: Cmd:       0x0000333a | Max curr: 0x00000000
      mmc0: sdhci: Resp[0]:   0x00000920 | Resp[1]:  0x001d8a33
      mmc0: sdhci: Resp[2]:   0x325b5900 | Resp[3]:  0x3f400e00
      mmc0: sdhci: Host ctl2: 0x00000000
      mmc0: sdhci: ADMA Err:  0x00000009 | ADMA Ptr: 0x000000236d43820c
      mmc0: sdhci: ============================================
      mmc0: error -5 whilst initialising SD card
      
      but can lead to other errors, and potentially direct the SDHCI
      controller to read/write data to other memory locations (e.g. if a valid
      descriptor is visible to the device in a stale cache line.)
      
      Fix this by ensuring that the DMA snoop bit corresponds with the
      behaviour of the DMA API.  Since the driver currently only supports DT,
      use of_dma_is_coherent().  Note that device_get_dma_attr() can not be
      used as that risks re-introducing this bug if/when the driver is
      converted to ACPI.
      
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Acked-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      121bd08b
    • Russell King's avatar
      mmc: sdhci: improve ADMA error reporting · d1c536e3
      Russell King authored
      
      
      ADMA errors are potentially data corrupting events; although we print
      the register state, we do not usefully print the ADMA descriptors.
      Worse than that, we print them by referencing their virtual address
      which is meaningless when the register state gives us the DMA address
      of the failing descriptor.
      
      Print the ADMA descriptors giving their DMA addresses rather than their
      virtual addresses, and print them using SDHCI_DUMP() rather than DBG().
      
      We also do not show the correct value of the interrupt status register;
      the register dump shows the current value, after we have cleared the
      pending interrupts we are going to service.  What is more useful is to
      print the interrupts that _were_ pending at the time the ADMA error was
      encountered.  Fix that too.
      
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Acked-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      d1c536e3
  2. 13 Sep, 2019 3 commits
    • Ulf Hansson's avatar
      mmc: tmio: Fixup runtime PM management during remove · 87b5d602
      Ulf Hansson authored
      
      
      Accessing the device when it may be runtime suspended is a bug, which is
      the case in tmio_mmc_host_remove(). Let's fix the behaviour.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Tested-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      87b5d602
    • Ulf Hansson's avatar
      mmc: tmio: Fixup runtime PM management during probe · aa86f1a3
      Ulf Hansson authored
      
      
      The tmio_mmc_host_probe() calls pm_runtime_set_active() to update the
      runtime PM status of the device, as to make it reflect the current status
      of the HW. This works fine for most cases, but unfortunate not for all.
      Especially, there is a generic problem when the device has a genpd attached
      and that genpd have the ->start|stop() callbacks assigned.
      
      More precisely, if the driver calls pm_runtime_set_active() during
      ->probe(), genpd does not get to invoke the ->start() callback for it,
      which means the HW isn't really fully powered on. Furthermore, in the next
      phase, when the device becomes runtime suspended, genpd will invoke the
      ->stop() callback for it, potentially leading to usage count imbalance
      problems, depending on what's implemented behind the callbacks of course.
      
      To fix this problem, convert to call pm_runtime_get_sync() from
      tmio_mmc_host_probe() rather than pm_runtime_set_active(). Additionally, to
      avoid bumping usage counters and unnecessary re-initializing the HW the
      first time the tmio driver's ->runtime_resume() callback is called,
      introduce a state flag to keeping track of this.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Tested-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      aa86f1a3
    • Ulf Hansson's avatar
      Revert "mmc: tmio: move runtime PM enablement to the driver implementations" · 8861474a
      Ulf Hansson authored
      This reverts commit 7ff21319.
      
      It turns out that the above commit introduces other problems. For example,
      calling pm_runtime_set_active() must not be done prior calling
      pm_runtime_enable() as that makes it fail. This leads to additional
      problems, such as clock enables being wrongly balanced.
      
      Rather than fixing the problem on top, let's start over by doing a revert.
      
      Fixes: 7ff21319
      
       ("mmc: tmio: move runtime PM enablement to the driver implementations")
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Tested-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      8861474a
  3. 12 Sep, 2019 2 commits
  4. 11 Sep, 2019 30 commits