1. 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
  2. 11 8月, 2010 2 次提交
  3. 28 5月, 2010 1 次提交
  4. 13 3月, 2010 1 次提交
  5. 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
  6. 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
  7. 23 9月, 2009 7 次提交
  8. 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
  9. 04 5月, 2009 1 次提交
  10. 31 3月, 2009 1 次提交
  11. 25 3月, 2009 3 次提交
  12. 01 1月, 2009 2 次提交
  13. 09 11月, 2008 1 次提交
  14. 02 8月, 2008 1 次提交
  15. 15 7月, 2008 2 次提交
    • P
      mmc,sdio: helper function for transfer padding · ad3868b2
      Pierre Ossman 提交于
      There are a lot of crappy controllers out there that cannot handle
      all the request sizes that the MMC/SD/SDIO specifications require.
      In case the card driver can pad the data to overcome the problems,
      this commit adds a helper that calculates how much that padding
      should be.
      
      A corresponding helper is also added for SDIO, but it can also deal
      with all the complexities of splitting up a large transfer efficiently.
      Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>
      ad3868b2
    • A
      mmc: add support for card-detection polling · 28f52482
      Anton Vorontsov 提交于
      Some hosts (and boards that use mmc_spi) do not use interrupts on the CD
      line, so they can't trigger mmc_detect_change. We want to poll the card
      and see if there was a change. 1 second poll interval seems resonable.
      
      This patch also implements .get_cd() host operation, that could be used
      by the hosts that are able to report card-detect status without need to
      talk MMC.
      Signed-off-by: NAnton Vorontsov <avorontsov@ru.mvista.com>
      Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>
      28f52482
  16. 19 4月, 2008 2 次提交
  17. 02 11月, 2007 1 次提交
  18. 24 9月, 2007 10 次提交
    • P
      mmc: add led trigger · af8350c7
      Pierre Ossman 提交于
      Add a led trigger for each host controller that indicates if there
      is a request active on the controller.
      Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>
      af8350c7
    • D
      MMC core learns about SPI · af517150
      David Brownell 提交于
      Teach the MMC/SD/SDIO core about using SPI mode.
      
       - Use mmc_host_is_spi() so enumeration works through SPI signaling
         and protocols, not just the native versions.
      
       - Provide the SPI response type flags with each request issued,
         including requests from the new lock/unlock code.
      
       - Understand that cmd->resp[0] and mmc_get_status() results for SPI
         return different values than for "native" MMC/SD protocol; this
         affects resetting, checking card lock status, and some others.
      
       - Understand that some commands act a bit differently ... notably:
           * OP_COND command doesn't return the OCR
           * APP_CMD status doesn't have an R1_APP_CMD analogue
      
      Those changes required some new and updated primitives:
      
       - Provide utilities to access two SPI-only requests, and one
         request that wasn't previously needed:
           * mmc_spi_read_ocr() ... SPI only
           * mmc_spi_set_crc() ... SPI only (override by module parm)
           * mmc_send_cid() ... for use without broadcast mode
      
       - Updated internal routines:
           * Previous mmc_send_csd() modified into mmc_send_cxd_native();
             it uses native "R2" responses, which include 16 bytes of data.
           * Previous mmc_send_ext_csd() becomes new mmc_send_cxd_data()
             helper for command-and-data access
           * Bugfix to that mmc_send_cxd_data() code:  dma-to-stack is
             unsafe/nonportable, so kmalloc a bounce buffer instead.
      
       - Modified mmc_send_ext_csd() now uses mmc_send_cxd_data() helper
      
       - Modified mmc_send_csd(), and new mmc_spi_send_cid(), routines use
         those helper routines based on whether they're native or SPI
      
      The newest categories of cards supported by the MMC stack aren't expected
      to work yet with SPI:  MMC or SD cards with over 4GB data, and SDIO.
      All those cards support SPI mode, so eventually they should work too.
      Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>
      af517150
    • P
      mmc: increase power up delay · f9996aee
      Pierre Ossman 提交于
      Increase delay for power up in order to support some slower boards.
      
      Also add some comments about why the delays are there.
      Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>
      f9996aee
    • P
      mmc: replace BUG_ON with WARN_ON · d84075c8
      Pierre Ossman 提交于
      Replace all cases of BUG_ON with WARN_ON where there is a chance
      (with varying degrees of slim) that the kernel can continue without
      incidence.
      Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>
      d84075c8
    • P
      mmc: fix sdio timeout calculation · e6f918bf
      Pierre Ossman 提交于
      SDIO doesn't have a CSD so it uses different timeout values than
      SD memory.
      Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>
      e6f918bf
    • P
      mmc: fix incorrect divisor in debug output · ce252edd
      Pierre Ossman 提交于
      Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>
      ce252edd
    • N
      sdio: allow for mmc_claim_host to be aborted · 2342f332
      Nicolas Pitre 提交于
      It is sometimes necessary to give up on trying to claim the host lock,
      especially if that happens in a thread that has to be stopped.
      
      While at it, fix the description for mmc_claim_host() which was wrong.
      Signed-off-by: NNicolas Pitre <npitre@mvista.com>
      Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>
      2342f332
    • N
      mmc: initialize mmc subsystem with subsys_initcall() · 26074962
      Nicolas Pitre 提交于
      The problem is that the sdio_bus must be registered before any SDIO
      drivers are registered against it otherwise the kernel sulks.  Because
      the sdio_bus registration happens through module_init (equivalent to
      device_initcall), then any SDIO
      drivers linked before the SDIO core code in the kernel will be initialized
      first.
      
      Upcoming SDIO function drivers are likely to be located outside the
      drivers/mmc directory as it is common practice to group drivers according
      to their function rather than the bus they use.  SDIO drivers are therefore
      likely to appear at random location in the kernel link.
      
      To make sure the sdio_bus is always initialized before any SDIO drivers,
      let's move the MMC init to the subsys_initcall level.
      Signed-off-by: NNicolas Pitre <npitre@mvista.com>
      Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>
      26074962
    • P
      mmc: basic SDIO device model · e29a7d73
      Pierre Ossman 提交于
      Add the sdio bus type and basic device handling.
      Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>
      e29a7d73
    • P
      mmc: detect SDIO cards · 5c4e6f13
      Pierre Ossman 提交于
      Really basic init sequence for SDIO cards.
      Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>
      5c4e6f13