1. 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
  2. 11 Sep, 2019 2 commits
  3. 03 Sep, 2019 1 commit
    • Jan Kaisrlik's avatar
      Revert "mmc: core: do not retry CMD6 in __mmc_switch()" · 8ad8e02c
      Jan Kaisrlik authored
      Turns out the commit 3a0681c7 ("mmc: core: do not retry CMD6 in
      __mmc_switch()") breaks initialization of a Toshiba THGBMNG5 eMMC card,
      when using the meson-gx-mmc.c driver on a custom board based on Amlogic
      A113D.
      
      The CMD6 that switches the card into HS200 mode is then one that fails and
      according to the below printed messages from the log:
      
      [    1.648951] mmc0: mmc_select_hs200 failed, error -84
      [    1.648988] mmc0: error -84 whilst initialising MMC card
      
      After some analyze, it turns out that adding a delay of ~5ms inside
      mmc_select_bus_width() but after mmc_compare_ext_csds() has been executed,
      also fixes the problem. Adding yet some more debug code, trying to figure
      out if potentially the card could be in a busy state, both by using CMD13
      and ->card_busy() ops concluded that this was not the case.
      
      Therefore, let's simply revert the commit that dropped support for retrying
      of CMD6, as this also fixes the problem.
      
      Fixes: 3a0681c7 ("mmc: core: do not retry CMD6 in __mmc_switch()")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJan Kaisrlik <ja.kaisrlik@gmail.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      8ad8e02c
  4. 30 Aug, 2019 7 commits
  5. 22 Aug, 2019 1 commit
  6. 21 Aug, 2019 1 commit
  7. 06 Aug, 2019 3 commits
    • Kevin Hao's avatar
      mmc: cavium: Add the missing dma unmap when the dma has finished. · b803974a
      Kevin Hao authored
      This fixes the below calltrace when the CONFIG_DMA_API_DEBUG is enabled.
        DMA-API: thunderx_mmc 0000:01:01.4: cpu touching an active dma mapped cacheline [cln=0x000000002fdf9800]
        WARNING: CPU: 21 PID: 1 at kernel/dma/debug.c:596 debug_dma_assert_idle+0x1f8/0x270
        Modules linked in:
        CPU: 21 PID: 1 Comm: init Not tainted 5.3.0-rc1-next-20190725-yocto-standard+ #64
        Hardware name: Marvell OcteonTX CN96XX board (DT)
        pstate: 80400009 (Nzcv daif +PAN -UAO)
        pc : debug_dma_assert_idle+0x1f8/0x270
        lr : debug_dma_assert_idle+0x1f8/0x270
        sp : ffff0000113cfc10
        x29: ffff0000113cfc10 x28: 0000ffff8c880000
        x27: ffff800bc72a0000 x26: ffff000010ff8000
        x25: ffff000010ff8940 x24: ffff000010ff8968
        x23: 0000000000000000 x22: ffff000010e83700
        x21: ffff000010ea2000 x20: ffff000010e835c8
        x19: ffff800bc2c73300 x18: ffffffffffffffff
        x17: 0000000000000000 x16: 0000000000000000
        x15: ffff000010e835c8 x14: 6d20616d64206576
        x13: 69746361206e6120 x12: 676e696863756f74
        x11: 20757063203a342e x10: 31303a31303a3030
        x9 : 303020636d6d5f78 x8 : 3230303030303030
        x7 : 00000000000002fd x6 : ffff000010fd57d0
        x5 : 0000000000000000 x4 : ffff0000106c5210
        x3 : 00000000ffffffff x2 : 0000800bee9c0000
        x1 : 57d5843f4aa62800 x0 : 0000000000000000
        Call trace:
         debug_dma_assert_idle+0x1f8/0x270
         wp_page_copy+0xb0/0x688
         do_wp_page+0xa8/0x5b8
         __handle_mm_fault+0x600/0xd00
         handle_mm_fault+0x118/0x1e8
         do_page_fault+0x200/0x500
         do_mem_abort+0x50/0xb0
         el0_da+0x20/0x24
        ---[ end trace a005534bd23e109f ]---
        DMA-API: Mapped at:
         debug_dma_map_sg+0x94/0x350
         cvm_mmc_request+0x3c4/0x988
         __mmc_start_request+0x9c/0x1f8
         mmc_start_request+0x7c/0xb0
         mmc_blk_mq_issue_rq+0x5c4/0x7b8
      Signed-off-by: default avatarKevin Hao <haokexin@gmail.com>
      Fixes: ba3869ff ("mmc: cavium: Add core MMC driver for Cavium SOCs")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      b803974a
    • Kevin Hao's avatar
      mmc: cavium: Set the correct dma max segment size for mmc_host · fa25eba6
      Kevin Hao authored
      We have set the mmc_host.max_seg_size to 8M, but the dma max segment
      size of PCI device is set to 64K by default in function pci_device_add().
      The mmc_host.max_seg_size is used to set the max segment size of
      the blk queue. Then this mismatch will trigger a calltrace like below
      when a bigger than 64K segment request arrives at mmc dev. So we should
      consider the limitation of the cvm_mmc_host when setting the
      mmc_host.max_seg_size.
        DMA-API: thunderx_mmc 0000:01:01.4: mapping sg segment longer than device claims to support [len=131072] [max=65536]
        WARNING: CPU: 6 PID: 238 at kernel/dma/debug.c:1221 debug_dma_map_sg+0x2b8/0x350
        Modules linked in:
        CPU: 6 PID: 238 Comm: kworker/6:1H Not tainted 5.3.0-rc1-next-20190724-yocto-standard+ #62
        Hardware name: Marvell OcteonTX CN96XX board (DT)
        Workqueue: kblockd blk_mq_run_work_fn
        pstate: 80c00009 (Nzcv daif +PAN +UAO)
        pc : debug_dma_map_sg+0x2b8/0x350
        lr : debug_dma_map_sg+0x2b8/0x350
        sp : ffff00001770f9e0
        x29: ffff00001770f9e0 x28: ffffffff00000000
        x27: 00000000ffffffff x26: ffff800bc2c73180
        x25: ffff000010e83700 x24: 0000000000000002
        x23: 0000000000000001 x22: 0000000000000001
        x21: 0000000000000000 x20: ffff800bc48ba0b0
        x19: ffff800bc97e8c00 x18: ffffffffffffffff
        x17: 0000000000000000 x16: 0000000000000000
        x15: ffff000010e835c8 x14: 6874207265676e6f
        x13: 6c20746e656d6765 x12: 7320677320676e69
        x11: 7070616d203a342e x10: 31303a31303a3030
        x9 : 303020636d6d5f78 x8 : 35363d78616d5b20
        x7 : 00000000000002fd x6 : ffff000010fd57dc
        x5 : 0000000000000000 x4 : ffff0000106c61f0
        x3 : 00000000ffffffff x2 : 0000800bee060000
        x1 : 7010678df3041a00 x0 : 0000000000000000
        Call trace:
         debug_dma_map_sg+0x2b8/0x350
         cvm_mmc_request+0x3c4/0x988
         __mmc_start_request+0x9c/0x1f8
         mmc_start_request+0x7c/0xb0
         mmc_blk_mq_issue_rq+0x5c4/0x7b8
         mmc_mq_queue_rq+0x11c/0x278
         blk_mq_dispatch_rq_list+0xb0/0x568
         blk_mq_do_dispatch_sched+0x6c/0x108
         blk_mq_sched_dispatch_requests+0x110/0x1b8
         __blk_mq_run_hw_queue+0xb0/0x118
         blk_mq_run_work_fn+0x28/0x38
         process_one_work+0x210/0x490
         worker_thread+0x48/0x458
         kthread+0x130/0x138
         ret_from_fork+0x10/0x1c
      Signed-off-by: default avatarKevin Hao <haokexin@gmail.com>
      Fixes: ba3869ff ("mmc: cavium: Add core MMC driver for Cavium SOCs")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      fa25eba6
    • Baolin Wang's avatar
      mmc: sdhci-sprd: Fix the incorrect soft reset operation when runtime resuming · c6303c5d
      Baolin Wang authored
      The SD host controller specification defines 3 types software reset:
      software reset for data line, software reset for command line and software
      reset for all. Software reset for all means this reset affects the entire
      Host controller except for the card detection circuit.
      
      In sdhci_runtime_resume_host() we always do a software "reset for all",
      which causes the Spreadtrum variant controller to work abnormally after
      resuming. To fix the problem, let's do a software reset for the data and
      the command part, rather than "for all".
      
      However, as sdhci_runtime_resume() is a common sdhci function and we don't
      want to change the behaviour for other variants, let's introduce a new
      in-parameter for it. This enables the caller to decide if a "reset for all"
      shall be done or not.
      Signed-off-by: default avatarBaolin Wang <baolin.wang@linaro.org>
      Fixes: fb8bd90f ("mmc: sdhci-sprd: Add Spreadtrum's initial host controller")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      c6303c5d
  8. 22 Jul, 2019 4 commits
    • Andreas Koop's avatar
      mmc: mmc_spi: Enable stable writes · 3a6ffb3c
      Andreas Koop authored
      While using the mmc_spi driver occasionally errors like this popped up:
      
      mmcblk0: error -84 transferring data end_request: I/O error, dev mmcblk0, sector 581756
      
      I looked on the Internet for occurrences of the same problem and came
      across a helpful post [1]. It includes source code to reproduce the bug.
      There is also an analysis about the cause. During transmission data in the
      supplied buffer is being modified. Thus the previously calculated checksum
      is not correct anymore.
      
      After some digging I found out that device drivers are supposed to report
      they need stable writes. To fix this I set the appropriate flag at queue
      initialization if CRC checksumming is enabled for that SPI host.
      
      [1]
      https://groups.google.com/forum/#!msg/sim1/gLlzWeXGFr8/KevXinUXfc8JSigned-off-by: default avatarAndreas Koop <andreas.koop@zf.com>
      [shihpo: Rebase on top of v5.3-rc1]
      Signed-off-by: default avatarShihPo Hung <shihpo.hung@sifive.com>
      Cc: Paul Walmsley <paul.walmsley@sifive.com>
      CC: stable@vger.kernel.org
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      3a6ffb3c
    • Joe Perches's avatar
      mmc: meson-mx-sdio: Fix misuse of GENMASK macro · 665e985c
      Joe Perches authored
      Arguments are supposed to be ordered high then low.
      Signed-off-by: default avatarJoe Perches <joe@perches.com>
      Reviewed-by: default avatarNeil Armstrong <narmstrong@baylibre.com>
      Fixes: ed80a13b ("mmc: meson-mx-sdio: Add a driver for the Amlogic
      Meson8 and Meson8b SoCs")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      665e985c
    • Douglas Anderson's avatar
      mmc: dw_mmc: Fix occasional hang after tuning on eMMC · ba2d139b
      Douglas Anderson authored
      In commit 46d17952 ("mmc: dw_mmc: Wait for data transfer after
      response errors.") we fixed a tuning-induced hang that I saw when
      stress testing tuning on certain SD cards.  I won't re-hash that whole
      commit, but the summary is that as a normal part of tuning you need to
      deal with transfer errors and there were cases where these transfer
      errors was putting my system into a bad state causing all future
      transfers to fail.  That commit fixed handling of the transfer errors
      for me.
      
      In downstream Chrome OS my fix landed and had the same behavior for
      all SD/MMC commands.  However, it looks like when the commit landed
      upstream we limited it to only SD tuning commands.  Presumably this
      was to try to get around problems that Alim Akhtar reported on exynos
      [1].
      
      Unfortunately while stress testing reboots (and suspend/resume) on
      some rk3288-based Chromebooks I found the same problem on the eMMC on
      some of my Chromebooks (the ones with Hynix eMMC).  Since the eMMC
      tuning command is different (MMC_SEND_TUNING_BLOCK_HS200
      vs. MMC_SEND_TUNING_BLOCK) we were basically getting back into the
      same situation.
      
      I'm hoping that whatever problems exynos was having in the past are
      somehow magically fixed now and we can make the behavior the same for
      all commands.
      
      [1] https://lkml.kernel.org/r/CAGOxZ53WfNbaMe0_AM0qBqU47kAfgmPBVZC8K8Y-_J3mDMqW4A@mail.gmail.com
      
      Fixes: 46d17952 ("mmc: dw_mmc: Wait for data transfer after response errors.")
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Cc: Marek Szyprowski <m.szyprowski@samsung.com>
      Cc: Alim Akhtar <alim.akhtar@gmail.com>
      Cc: Enric Balletbo i Serra <enric.balletbo@collabora.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      ba2d139b
    • Baolin Wang's avatar
      mmc: host: sdhci-sprd: Fix the missing pm_runtime_put_noidle() · fc62113b
      Baolin Wang authored
      When the SD host controller tries to probe again due to the derferred
      probe mechanism, it will always keep the SD host device as runtime
      resume state due to missing the runtime put operation in error path
      last time.
      
      Thus add the pm_runtime_put_noidle() in error path to make the PM runtime
      counter balance, which can make the SD host device's PM runtime work well.
      Signed-off-by: default avatarBaolin Wang <baolin.wang@linaro.org>
      Acked-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Fixes: fb8bd90f ("mmc: sdhci-sprd: Add Spreadtrum's initial host controller")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      fc62113b
  9. 10 Jul, 2019 15 commits
  10. 20 Jun, 2019 1 commit
  11. 19 Jun, 2019 2 commits