1. 21 May, 2019 1 commit
  2. 08 Oct, 2018 1 commit
  3. 20 Jun, 2017 1 commit
    • Linus Walleij's avatar
      mmc: core: Delete bounce buffer Kconfig option · c3dccb74
      Linus Walleij authored
      This option is activated by all multiplatform configs and what
      not so we almost always have it turned on, and the memory it
      saves is negligible, even more so moving forward. The actual
      bounce buffer only gets allocated only when used, the only
      thing the ifdefs are saving is a little bit of code.
      It is highly improper to have this as a Kconfig option that
      get turned on by Kconfig, make this a pure runtime-thing and
      let the host decide whether we use bounce buffers. We add a
      new property "disable_bounce" to the host struct.
      Notice that mmc_queue_calc_bouncesz() already disables the
      bounce buffers if host->max_segs != 1, so any arch that has a
      maximum number of segments higher than 1 will have bounce
      buffers disabled.
      The option CONFIG_MMC_BLOCK_BOUNCE is default y so the
      majority of platforms in the kernel already have it on, and
      it then gets turned off at runtime since most of these have
      a host->max_segs > 1. The few exceptions that have
      host->max_segs == 1 and still turn off the bounce buffering
      are those that disable it in their defconfig.
      Those are the following:
      - Uses MMC_PXA, drivers/mmc/host/pxamci.c
      - Sets host->max_segs = NR_SG, which is 1
      - This needs its bounce buffer deactivated so we set
        host->disable_bounce to true in the host driver
      - Uses MMC_DAVINCI, drivers/mmc/host/davinci_mmc.c
      - This driver sets host->max_segs to MAX_NR_SG, which is 16
      - That means this driver anyways disabled bounce buffers
      - No special action needed for this platform
      - Uses MMC_ARMMMCI, drivers/mmc/host/mmci.[c|h]
      - This driver by default sets host->max_segs to NR_SG,
        which is 128, unless a DMA engine is used, and in that case
        the number of segments are also > 1
      - That means this driver already disables bounce buffers
      - No special action needed for these platforms
      - Uses drivers/mmc/host/sdhci.c
      - Normally sets host->max_segs to SDHCI_MAX_SEGS which is 128 and
        thus disables bounce buffers
      - Sets host->max_segs to 1 if SDHCI_USE_SDMA is set
      - SDHCI_USE_SDMA is only set by SDHCI on PCI adapers
      - That means that for this platform bounce buffers are already
        disabled at runtime
      - No special action needed for this platform
      - Uses MMC_SPI (a simple MMC card connected on SPI pins)
      - Uses drivers/mmc/host/mmc_spi.c
      - Sets host->max_segs to MMC_SPI_BLOCKSATONCE which is 128
      - That means this platform already disables bounce buffers at
      - No special action needed for these platforms
      - Uses MMC_CAVIUM_OCTEON, drivers/mmc/host/cavium.c
      - Sets host->max_segs to 16 or 1
      - Setting host->disable_bounce to be sure for the 1 case
      - Uses MMC_JZ4740, drivers/mmc/host/jz4740_mmc.c
      - This sets host->max_segs to 128 so bounce buffers are
        already runtime disabled
      - No action needed for this platform
      It would be interesting to come up with a list of the platforms
      that actually end up using bounce buffers. I have not been
      able to infer such a list, but it occurs when
      host->max_segs == 1 and the bounce buffering is not explicitly
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
  4. 13 Feb, 2017 1 commit
  5. 12 Dec, 2016 1 commit
    • Ulf Hansson's avatar
      mmc: block: Move files to core · f397c8d8
      Ulf Hansson authored
      Once upon a time it made sense to keep the mmc block device driver and its
      related code, in its own directory called card. Over time, more an more
      functions/structures have become shared through generic mmc header files,
      between the core and the card directory. In other words, the relationship
      between them has become closer.
      By sharing functions/structures via generic header files, it becomes easy
      for outside users to abuse them. In a way to avoid that from happen, let's
      move the files from card directory into the core directory, as it enables
      us to move definitions of functions/structures into mmc core specific
      header files.
      Note, this is only the first step in providing a cleaner mmc interface for
      outside users. Following changes will do the actual cleanup, as that is not
      part of this change.
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Reviewed-by: default avatarLinus Walleij <linus.walleij@linaro.org>
  6. 02 May, 2016 1 commit
    • Srinivas Kandagatla's avatar
      mmc: pwrseq: convert to proper platform device · d97a1e5d
      Srinivas Kandagatla authored
      simple-pwrseq and emmc-pwrseq drivers rely on platform_device
      structure from of_find_device_by_node(), this works mostly. But, as there
      is no driver associated with this devices, cases like default/init pinctrl
      setup would never be performed by pwrseq. This becomes problem when the
      gpios used in pwrseq require pinctrl setup.
      Currently most of the common pinctrl setup is done in
      drivers/base/pinctrl.c by pinctrl_bind_pins().
      There are two ways to solve this issue on either convert pwrseq drivers
      to a proper platform drivers or copy the exact code from
      pcintrl_bind_pins(). I prefer converting pwrseq to proper drivers so that
      other cases like setting up clks/parents from dt would also be possible.
      Signed-off-by: default avatarSrinivas Kandagatla <srinivas.kandagatla@linaro.org>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
  7. 26 Oct, 2015 1 commit
    • Ulf Hansson's avatar
      mmc: core: Remove MMC_CLKGATE · 9eadcc05
      Ulf Hansson authored
      MMC_CLKGATE was once invented to save power by gating the bus clock at
      request inactivity. At that time it served its purpose. The modern way to
      deal with power saving for these scenarios, is by using runtime PM.
      Nowadays, several host drivers have deployed runtime PM, but for those
      that haven't and which still cares power saving at request inactivity,
      it's certainly time to deploy runtime PM as it has been around for several
      years now.
      To simplify code to mmc core and thus decrease maintenance efforts, this
      patch removes all code related to MMC_CLKGATE.
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Reviewed-by: default avatarLinus Walleij <linus.walleij@linaro.org>
  8. 14 Feb, 2014 1 commit
  9. 11 Jan, 2013 1 commit
  10. 09 Jan, 2011 1 commit
    • Linus Walleij's avatar
      mmc: Aggressive clock gating framework · 04566831
      Linus Walleij authored
      This patch modifies the MMC core code to optionally call the set_ios()
      operation on the driver with the clock frequency set to 0 (gate) after
      a grace period of at least 8 MCLK cycles, then restore it (ungate)
      before any new request. This gives the driver the option to shut down
      the MCI clock to the MMC/SD card when the clock frequency is 0, i.e.
      the core has stated that the MCI clock does not need to be generated.
      It is inspired by existing clock gating code found in the OMAP and
      Atmel drivers and brings this up to the host abstraction.  Gating is
      performed before and after any MMC request.
      This patchset implements this for the MMCI/PL180 MMC/SD host controller,
      but it should be simple to switch OMAP/Atmel over to using this instead.
      mmc_set_{gated,ungated}() add variable protection to the state holders
      for the clock gating code.  This is particularly important when ordinary
      .set_ios() calls would race with the .set_ios() call resulting from a
      delayed gate operation.
      Signed-off-by: default avatarLinus Walleij <linus.walleij@stericsson.com>
      Reviewed-by: default avatarChris Ball <cjb@laptop.org>
      Tested-by: default avatarChris Ball <cjb@laptop.org>
      Signed-off-by: default avatarChris Ball <cjb@laptop.org>
  11. 15 Dec, 2009 1 commit
    • Ben Hutchings's avatar
      mmc: add module parameter to set whether cards are assumed removable · bd68e083
      Ben Hutchings authored
      Some people run general-purpose distribution kernels on netbooks with
      a card that is physically non-removable or logically non-removable
      (e.g. used for /home) and cannot be cleanly unmounted during suspend.
      Add a module parameter to set whether cards are assumed removable or
      non-removable, with the default set by CONFIG_MMC_UNSAFE_RESUME.
      In general, it is not possible to tell whether a card present in an MMC
      slot after resume is the same that was there before suspend.  So there are
      two possible behaviours, each of which will cause data loss in some cases:
      CONFIG_MMC_UNSAFE_RESUME=n (default): Cards are assumed to be removed
      during suspend.  Any filesystem on them must be unmounted before suspend;
      otherwise, buffered writes will be lost.
      CONFIG_MMC_UNSAFE_RESUME=y: Cards are assumed to remain present during
      suspend.  They must not be swapped during suspend; otherwise, buffered
      writes will be flushed to the wrong card.
      Currently the choice is made at compile time and this allows that to be
      overridden at module load time.
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      Cc: Wouter van Heyst <larstiq@larstiq.dyndns.org>
      Cc: <linux-mmc@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  12. 08 May, 2007 1 commit
  13. 01 May, 2007 1 commit
    • Pierre Ossman's avatar
      mmc: support unsafe resume of cards · 6abaa0c9
      Pierre Ossman authored
      Since many have the system root on MMC/SD we must allow some foot
      shooting when it comes to resume.
      We cannot detect if a card is removed and reinserted during suspend,
      so the safe approach would be to assume it was, avoiding potential
      filesystem corruption. This will of course not work if you cannot
      release the card before suspend.
      This commit adds a compile time option that makes the MMC layer
      assume the card wasn't touched if it is redetected upon resume.
      Signed-off-by: default avatarPierre Ossman <drzeus@drzeus.cx>