1. 18 3月, 2011 1 次提交
  2. 17 3月, 2011 1 次提交
  3. 16 3月, 2011 1 次提交
  4. 09 3月, 2011 1 次提交
  5. 09 1月, 2011 7 次提交
  6. 24 12月, 2010 1 次提交
    • T
      mmc: update workqueue usages · 0d9ee5b2
      Tejun Heo 提交于
      Workqueue creation API has been updated and flush_scheduled_work() is
      deprecated and scheduled to be removed.
      
      * core/core.c: Use alloc_ordered_workqueue() instead of
        create_singlethread_workqueue().  This removes an unnecessary
        rescuer.
      
      * host/omap.c: Create, use and flush mmc_omap_wq instead of the
        system_wq.
      
      * Flush host->mmc_carddetect_work directly on removal instead of using
        flush_scheduled_work().
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Chris Ball <cjb@laptop.org>
      Cc: linux-mmc@vger.kernel.org
      0d9ee5b2
  7. 22 12月, 2010 1 次提交
  8. 12 11月, 2010 1 次提交
  9. 23 10月, 2010 7 次提交
  10. 16 10月, 2010 1 次提交
    • O
      mmc: sdio: fix SDIO suspend/resume regression · 1c8cf9c9
      Ohad Ben-Cohen 提交于
      Fix SDIO suspend/resume regression introduced by 4c2ef25f "mmc: fix
      all hangs related to mmc/sd card insert/removal during suspend/resume":
      
        PM: Syncing filesystems ... done.
        Freezing user space processes ... (elapsed 0.01 seconds) done.
        Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
        Suspending console(s) (use no_console_suspend to debug)
        pm_op(): platform_pm_suspend+0x0/0x5c returns -38
        PM: Device pxa2xx-mci.0 failed to suspend: error -38
        PM: Some devices failed to suspend
      
      4c2ef25f moved the card removal/insertion mechanism out of MMC's
      suspend/resume path and into pm notifiers (mmc_pm_notify), and that
      broke SDIO's expectation that mmc_suspend_host() will remove the card,
      and squash the error, in case -ENOSYS is returned from the bus suspend
      handler (mmc_sdio_suspend() in this case).
      
      mmc_sdio_suspend() is using this whenever at least one of the card's SDIO
      function drivers does not have suspend/resume handlers - in that case
      it is agreed to force removal of the entire card.
      
      This patch fixes this regression by trivially bringing back that part of
      mmc_suspend_host(), which was removed by 4c2ef25f.
      Reported-and-tested-by: NSven Neumann <s.neumann@raumfeld.com>
      Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      Cc: Maxim Levitsky <maximlevitsky@gmail.com>
      Cc: <stable@kernel.org>
      Acked-by: NNicolas Pitre <nico@fluxnic.net>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      1c8cf9c9
  11. 12 8月, 2010 1 次提交
    • A
      mmc: add erase, secure erase, trim and secure trim operations · dfe86cba
      Adrian Hunter 提交于
      SD/MMC cards tend to support an erase operation.  In addition, eMMC v4.4
      cards can support secure erase, trim and secure trim operations that are
      all variants of the basic erase command.
      
      SD/MMC device attributes "erase_size" and "preferred_erase_size" have been
      added.
      
      "erase_size" is the minimum size, in bytes, of an erase operation.  For
      MMC, "erase_size" is the erase group size reported by the card.  Note that
      "erase_size" does not apply to trim or secure trim operations where the
      minimum size is always one 512 byte sector.  For SD, "erase_size" is 512
      if the card is block-addressed, 0 otherwise.
      
      SD/MMC cards can erase an arbitrarily large area up to and
      including the whole card.  When erasing a large area it may
      be desirable to do it in smaller chunks for three reasons:
      
          1. A single erase command will make all other I/O on the card
             wait.  This is not a problem if the whole card is being erased, but
             erasing one partition will make I/O for another partition on the
             same card wait for the duration of the erase - which could be a
             several minutes.
      
          2. To be able to inform the user of erase progress.
      
          3. The erase timeout becomes too large to be very useful.
             Because the erase timeout contains a margin which is multiplied by
             the size of the erase area, the value can end up being several
             minutes for large areas.
      
      "erase_size" is not the most efficient unit to erase (especially for SD
      where it is just one sector), hence "preferred_erase_size" provides a good
      chunk size for erasing large areas.
      
      For MMC, "preferred_erase_size" is the high-capacity erase size if a card
      specifies one, otherwise it is based on the capacity of the card.
      
      For SD, "preferred_erase_size" is the allocation unit size specified by
      the card.
      
      "preferred_erase_size" is in bytes.
      Signed-off-by: NAdrian Hunter <adrian.hunter@nokia.com>
      Acked-by: NJens Axboe <axboe@kernel.dk>
      Cc: Kyungmin Park <kmpark@infradead.org>
      Cc: Madhusudhan Chikkature <madhu.cr@ti.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Ben Gardiner <bengardiner@nanometrics.ca>
      Cc: <linux-mmc@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      dfe86cba
  12. 11 8月, 2010 2 次提交
  13. 28 5月, 2010 1 次提交
  14. 13 3月, 2010 1 次提交
  15. 07 3月, 2010 1 次提交
    • N
      sdio: introduce API for special power management features · da68c4eb
      Nicolas Pitre 提交于
      This patch series provides the core changes needed to allow SDIO cards to
      remain powered and active while the host system is suspended, and let them
      wake up the host system when needed.  This is used to implement
      wake-on-lan with SDIO wireless cards at the moment.  Patches to add that
      support to the libertas driver will be posted separately.
      
      This patch:
      
      Some SDIO cards have the ability to keep on running autonomously when the
      host system is suspended, and wake it up when needed.  This however
      requires that the host controller preserve power to the card, and
      configure itself appropriately for wake-up.
      
      There is however 4 layers of abstractions involved: the host controller
      driver, the MMC core code, the SDIO card management code, and the actual
      SDIO function driver.  To make things simple and manageable, host drivers
      must advertise their PM capabilities with a feature bitmask, then function
      drivers can query and set those features from their suspend method.  Then
      each layer in the suspend call chain is expected to act upon those bits
      accordingly.
      
      [akpm@linux-foundation.org: fix typo in comment]
      Signed-off-by: NNicolas Pitre <nico@marvell.com>
      Cc: <linux-mmc@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      da68c4eb
  16. 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
  17. 23 9月, 2009 7 次提交
  18. 14 6月, 2009 2 次提交
    • S
      MMC core: limit minimum initialization frequency to 400kHz · 8dfd0374
      Sascha Hauer 提交于
      Some controllers allow a much lower frequency than 400kHz.
      Keep the minimum frequency within sensible limits.
      Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
      8dfd0374
    • J
      mmc: mmc_rescan detects card change in one run · 94d89efb
      Jorg Schummer 提交于
      With this patch, mmc_rescan can detect the removal of an mmc card and
      the insertion of (possibly another) card in the same run. This means
      that a card change can be detected without having to call
      mmc_detect_change multiple times.
      
      This change generalises the core such that it can be easily used by
      hosts which provide a mechanism to detect only the presence of a card
      reader cover, which has to be taken off in order to insert a card. Other
      hosts ("card detect" or "MMC_CAP_NEEDS_POLL") each receive an event when
      a card is removed and when a card is inserted, so it is sufficient for
      them if mmc_rescan handles only one event at a time. "Cover detect"
      hosts, however, only receive events about the cover status. This means
      that between 2 subsequent events, both a card removal and a card
      insertion can occur. In this case, the pre-patch version of mmc_rescan
      would only detect the removal of the previous card but not the insertion
      of the new card.
      Signed-off-by: NJorg Schummer <ext-jorg.2.schummer@nokia.com>
      Signed-off-by: NPierre Ossman <pierre@ossman.eu>
      94d89efb
  19. 04 5月, 2009 1 次提交
  20. 31 3月, 2009 1 次提交