1. 05 3月, 2018 11 次提交
  2. 27 2月, 2018 5 次提交
  3. 14 2月, 2018 2 次提交
    • P
      mmc: bcm2835: Don't overwrite max frequency unconditionally · 118032be
      Phil Elwell 提交于
      The optional DT parameter max-frequency could init the max bus frequency.
      So take care of this, before setting the max bus frequency.
      
      Fixes: 660fc733 ("mmc: bcm2835: Add new driver for the sdhost controller.")
      Signed-off-by: NPhil Elwell <phil@raspberrypi.org>
      Signed-off-by: NStefan Wahren <stefan.wahren@i2se.com>
      Cc: <stable@vger.kernel.org> # 4.12+
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      118032be
    • J
      Revert "mmc: meson-gx: include tx phase in the tuning process" · fe0e5804
      Jerome Brunet 提交于
      This reverts commit 0a446976.
      
      This commit was initially intended to fix problems with hs200 and hs400
      on some boards, mainly the odroid-c2. The OC2 (Rev 0.2) I have performs
      well in this modes, so I could not confirm these issues.
      
      We've had several reports about the issues being still present on (some)
      OC2, so apparently, this change does not do what it was supposed to do.
      Maybe the eMMC signal quality is on the edge on the board. This may
      explain the variability we see in term of stability, but this is just a
      guess. Lowering the max_frequency to 100Mhz seems to do trick for those
      affected by the issue
      
      Worse, the commit created new issues (CRC errors and hangs) on other
      boards, such as the kvim 1 and 2, the p200 or the libretech-cc.
      
      According to amlogic, the Tx phase should not be tuned and left in its
      default configuration, so it is best to just revert the commit.
      
      Fixes: 0a446976 ("mmc: meson-gx: include tx phase in the tuning process")
      Cc: <stable@vger.kernel.org> # 4.14+
      Signed-off-by: NJerome Brunet <jbrunet@baylibre.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      fe0e5804
  4. 06 2月, 2018 1 次提交
  5. 02 2月, 2018 1 次提交
  6. 31 1月, 2018 2 次提交
    • G
      mmc: MMC_SDHI_{SYS,INTERNAL}_DMAC should depend on HAS_DMA · 56174d9a
      Geert Uytterhoeven 提交于
      If NO_DMA=y:
      
          ERROR: "bad_dma_ops" [drivers/mmc/host/renesas_sdhi_sys_dmac.ko] undefined!
          ERROR: "bad_dma_ops" [drivers/mmc/host/renesas_sdhi_internal_dmac.ko] undefined!
      
      Add dependencies on HAS_DMA to fix this.
      
      Fixes: e578afab ("mmc: renesas_sdhi: remove wrong depends on to enable compile test")
      Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      56174d9a
    • L
      mmc: sdhci: Implement an SDHCI-specific bounce buffer · bd9b9027
      Linus Walleij 提交于
      The bounce buffer is gone from the MMC core, and now we found out
      that there are some (crippled) i.MX boards out there that have broken
      ADMA (cannot do scatter-gather), and also broken PIO so they must
      use SDMA. Closer examination shows a less significant slowdown
      also on SDMA-only capable Laptop hosts.
      
      SDMA sets down the number of segments to one, so that each segment
      gets turned into a singular request that ping-pongs to the block
      layer before the next request/segment is issued.
      
      Apparently it happens a lot that the block layer send requests
      that include a lot of physically discontiguous segments. My guess
      is that this phenomenon is coming from the file system.
      
      These devices that cannot handle scatterlists in hardware can see
      major benefits from a DMA-contiguous bounce buffer.
      
      This patch accumulates those fragmented scatterlists in a physically
      contiguous bounce buffer so that we can issue bigger DMA data chunks
      to/from the card.
      
      When tested with a PCI-integrated host (1217:8221) that
      only supports SDMA:
      0b:00.0 SD Host controller: O2 Micro, Inc. OZ600FJ0/OZ900FJ0/OZ600FJS
              SD/MMC Card Reader Controller (rev 05)
      This patch gave ~1Mbyte/s improved throughput on large reads and
      writes when testing using iozone than without the patch.
      
      dmesg:
      sdhci-pci 0000:0b:00.0: SDHCI controller found [1217:8221] (rev 5)
      mmc0 bounce up to 128 segments into one, max segment size 65536 bytes
      mmc0: SDHCI controller on PCI [0000:0b:00.0] using DMA
      
      On the i.MX SDHCI controllers on the crippled i.MX 25 and i.MX 35
      the patch restores the performance to what it was before we removed
      the bounce buffers.
      
      Cc: Pierre Ossman <pierre@ossman.eu>
      Cc: Benoît Thébaudeau <benoit@wsystem.com>
      Cc: Fabio Estevam <fabio.estevam@nxp.com>
      Cc: Benjamin Beckmeyer <beckmeyer.b@rittal.de>
      Cc: stable@vger.kernel.org # v4.14+
      Fixes: de3ee99b ("mmc: Delete bounce buffer handling")
      Tested-by: NBenjamin Beckmeyer <beckmeyer.b@rittal.de>
      Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      bd9b9027
  7. 24 1月, 2018 1 次提交
  8. 22 1月, 2018 3 次提交
  9. 19 1月, 2018 5 次提交
  10. 18 1月, 2018 6 次提交
  11. 17 1月, 2018 3 次提交