1. 09 1月, 2011 1 次提交
    • L
      mmc: Aggressive clock gating framework · 04566831
      Linus Walleij 提交于
      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: NLinus Walleij <linus.walleij@stericsson.com>
      Reviewed-by: NChris Ball <cjb@laptop.org>
      Tested-by: NChris Ball <cjb@laptop.org>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      04566831
  2. 16 12月, 2009 1 次提交
    • B
      mmc: add module parameter to set whether cards are assumed removable · bd68e083
      Ben Hutchings 提交于
      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: NBen Hutchings <ben@decadent.org.uk>
      Cc: Wouter van Heyst <larstiq@larstiq.dyndns.org>
      Cc: <linux-mmc@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      bd68e083
  3. 09 5月, 2007 1 次提交
  4. 01 5月, 2007 1 次提交
    • P
      mmc: support unsafe resume of cards · 6abaa0c9
      Pierre Ossman 提交于
      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: NPierre Ossman <drzeus@drzeus.cx>
      6abaa0c9