1. 27 2月, 2018 6 次提交
  2. 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
  3. 06 2月, 2018 1 次提交
  4. 02 2月, 2018 1 次提交
  5. 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
  6. 24 1月, 2018 1 次提交
  7. 22 1月, 2018 3 次提交
  8. 19 1月, 2018 5 次提交
  9. 18 1月, 2018 7 次提交
  10. 17 1月, 2018 5 次提交
  11. 16 1月, 2018 1 次提交
  12. 15 1月, 2018 1 次提交
    • B
      mmc: sdhci-esdhc-imx: Fix i.MX53 eSDHCv3 clock · 499ed50f
      Benoît Thébaudeau 提交于
      Commit 5143c953 ("mmc: sdhci-esdhc-imx: Allow all supported
      prescaler values") made it possible to set SYSCTL.SDCLKFS to 0 in SDR
      mode, thus bypassing the SD clock frequency prescaler, in order to be
      able to get higher SD clock frequencies in some contexts. However, that
      commit missed the fact that this value is illegal on the eSDHCv3
      instance of the i.MX53. This seems to be the only exception on i.MX,
      this value being legal even for the eSDHCv2 instances of the i.MX53.
      
      Fix this issue by changing the minimum prescaler value if the i.MX53
      eSDHCv3 is detected. According to the i.MX53 reference manual, if
      DLLCTRL[10] can be set, then the controller is eSDHCv3, else it is
      eSDHCv2.
      
      This commit fixes the following issue, which was preventing the i.MX53
      Loco (IMX53QSB) board from booting Linux 4.15.0-rc5:
      [    1.882668] mmcblk1: error -84 transferring data, sector 2048, nr 8, cmd response 0x900, card status 0xc00
      [    2.002255] mmcblk1: error -84 transferring data, sector 2050, nr 6, cmd response 0x900, card status 0xc00
      [   12.645056] mmc1: Timeout waiting for hardware interrupt.
      [   12.650473] mmc1: sdhci: ============ SDHCI REGISTER DUMP ===========
      [   12.656921] mmc1: sdhci: Sys addr:  0x00000000 | Version:  0x00001201
      [   12.663366] mmc1: sdhci: Blk size:  0x00000004 | Blk cnt:  0x00000000
      [   12.669813] mmc1: sdhci: Argument:  0x00000000 | Trn mode: 0x00000013
      [   12.676258] mmc1: sdhci: Present:   0x01f8028f | Host ctl: 0x00000013
      [   12.682703] mmc1: sdhci: Power:     0x00000002 | Blk gap:  0x00000000
      [   12.689148] mmc1: sdhci: Wake-up:   0x00000000 | Clock:    0x0000003f
      [   12.695594] mmc1: sdhci: Timeout:   0x0000008e | Int stat: 0x00000000
      [   12.702039] mmc1: sdhci: Int enab:  0x107f004b | Sig enab: 0x107f004b
      [   12.708485] mmc1: sdhci: AC12 err:  0x00000000 | Slot int: 0x00001201
      [   12.714930] mmc1: sdhci: Caps:      0x07eb0000 | Caps_1:   0x08100810
      [   12.721375] mmc1: sdhci: Cmd:       0x0000163a | Max curr: 0x00000000
      [   12.727821] mmc1: sdhci: Resp[0]:   0x00000920 | Resp[1]:  0x00000000
      [   12.734265] mmc1: sdhci: Resp[2]:   0x00000000 | Resp[3]:  0x00000000
      [   12.740709] mmc1: sdhci: Host ctl2: 0x00000000
      [   12.745157] mmc1: sdhci: ADMA Err:  0x00000001 | ADMA Ptr: 0xc8049200
      [   12.751601] mmc1: sdhci: ============================================
      [   12.758110] print_req_error: I/O error, dev mmcblk1, sector 2050
      [   12.764135] Buffer I/O error on dev mmcblk1p1, logical block 0, lost sync page write
      [   12.775163] EXT4-fs (mmcblk1p1): mounted filesystem without journal. Opts: (null)
      [   12.782746] VFS: Mounted root (ext4 filesystem) on device 179:9.
      [   12.789151] mmcblk1: response CRC error sending SET_BLOCK_COUNT command, card status 0x900
      Signed-off-by: NBenoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
      Reported-by: NWladimir J. van der Laan <laanwj@gmail.com>
      Tested-by: NWladimir J. van der Laan <laanwj@gmail.com>
      Fixes: 5143c953 ("mmc: sdhci-esdhc-imx: Allow all supported prescaler values")
      Cc: <stable@vger.kernel.org> # v4.13+
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      499ed50f
  13. 12 1月, 2018 1 次提交
  14. 11 1月, 2018 3 次提交
  15. 09 1月, 2018 1 次提交