1. 12 1月, 2012 1 次提交
  2. 27 10月, 2011 5 次提交
  3. 21 7月, 2011 3 次提交
  4. 26 5月, 2011 1 次提交
  5. 25 5月, 2011 3 次提交
  6. 18 3月, 2011 1 次提交
  7. 23 10月, 2010 2 次提交
  8. 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
  9. 23 9月, 2009 1 次提交
  10. 01 1月, 2009 1 次提交
  11. 15 7月, 2008 1 次提交
    • 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
  12. 24 9月, 2007 4 次提交
  13. 23 9月, 2007 3 次提交
  14. 26 7月, 2007 1 次提交
  15. 01 5月, 2007 3 次提交
  16. 05 2月, 2007 1 次提交
    • P
      mmc: Add support for SDHC cards · fba68bd2
      Philip Langdale 提交于
      Thanks to the generous donation of an SDHC card by John Gilmore, and
      the surprisingly enlightened decision by the SD Card Association to
      publish useful specs, I've been able to bash out support for SDHC. The
      changes are not too profound:
      
      i) Add a card flag indicating the card uses block level addressing and
      check it in the block driver. As we never took advantage of byte-level
      addressing, this simply involves skipping the block -> byte
      translation when sending commands.
      
      ii) The layout of the CSD is changed - a set of fields are discarded
      to make space for a larger C_SIZE. We did not reference any of the
      discarded fields except those related to the C_SIZE.
      
      iii) Read and write timeouts are fixed values and not calculated from
      CSD values.
      
      iv) Before invoking SEND_APP_OP_COND, we must invoke the new
      SEND_IF_COND to inform the card we support SDHC.
      Signed-off-by: NPhilipl Langdale <philipl@overt.org>
      Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>
      fba68bd2
  17. 15 1月, 2007 1 次提交
  18. 16 9月, 2006 1 次提交
  19. 07 9月, 2006 1 次提交
  20. 20 5月, 2006 1 次提交
  21. 22 2月, 2006 1 次提交
  22. 02 2月, 2006 1 次提交
  23. 10 1月, 2006 2 次提交