1. 29 Jan, 2015 1 commit
  2. 19 Jan, 2015 1 commit
  3. 10 Nov, 2014 1 commit
  4. 23 Sep, 2014 1 commit
  5. 18 Sep, 2014 1 commit
  6. 12 May, 2014 3 commits
  7. 24 Feb, 2013 1 commit
  8. 06 Dec, 2012 1 commit
  9. 03 Oct, 2012 1 commit
    • Jaehoon Chung's avatar
      mmc: support BKOPS feature for eMMC · 950d56ac
      Jaehoon Chung authored
      Enable eMMC background operations (BKOPS) feature.
      
      If URGENT_BKOPS is set after a response, note that BKOPS are required.
      Immediately run BKOPS if required.  Read/write operations should be
      requested during BKOPS(LEVEL-1), then issue HPI to interrupt the
      ongoing BKOPS and service the foreground operation.
      (This patch only controls the LEVEL2/3.)
      
      When repeating the writing 1GB data, at a certain time, performance is
      decreased.  At that time, card triggers the Level-3 or Level-2.  After
      running bkops, performance is recovered.
      
      Future considerations:
       * Check BKOPS_LEVEL=1 and start BKOPS in a preventive manner.
       * Interrupt ongoing BKOPS before powering off the card.
       * How do we get BKOPS_STATUS value (periodically send ext_csd command)?
       * If using periodic bkops, also consider runtime_pm control.
      Signed-off-by: default avatarJaehoon Chung <jh80.chung@samsung.com>
      Signed-off-by: default avatarKyungmin Park <kyungmin.park@samsung.com>
      Signed-off-by: default avatarKonstantin Dorfman <kdorfman@codeaurora.org>
      Reviewed-by: default avatarMaya Erez <merez@codeaurora.org>
      Signed-off-by: default avatarChris Ball <cjb@laptop.org>
      950d56ac
  10. 09 May, 2012 1 commit
  11. 25 Mar, 2012 1 commit
  12. 12 Jan, 2012 1 commit
  13. 11 Jan, 2012 1 commit
  14. 26 Oct, 2011 8 commits
  15. 20 Jul, 2011 2 commits
  16. 25 May, 2011 1 commit
  17. 24 May, 2011 4 commits
  18. 15 Mar, 2011 1 commit
    • Chuanxiao Dong's avatar
      mmc: export eMMC4.4 enhanced area details to sysfs · 709de99d
      Chuanxiao Dong authored
      Enhanced area feature is a new feature defined in eMMC4.4 standard. This
      user data area provides higher performance/reliability, at the expense
      of using twice the effective media space due to the area using SLC.
      
      The MMC driver now reads out the enhanced area offset and size and adds
      them to the device attributes in sysfs. Enabling the enhanced area can
      only be done once, and should be done in manufacturing. To use this
      feature, bit ERASE_GRP_DEF should also be set.
      
      Documentation/ABI/testing/sysfs-devices-mmc describes the two new
      attributes.
      Signed-off-by: default avatarChuanxiao Dong <chuanxiao.dong@intel.com>
      Reviewed-by: default avatarChris Ball <cjb@laptop.org>
      Signed-off-by: default avatarChris Ball <cjb@laptop.org>
      709de99d
  19. 08 Jan, 2011 1 commit
  20. 23 Oct, 2010 1 commit
  21. 12 Aug, 2010 1 commit
    • Adrian Hunter's avatar
      mmc: add erase, secure erase, trim and secure trim operations · dfe86cba
      Adrian Hunter authored
      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: default avatarAdrian Hunter <adrian.hunter@nokia.com>
      Acked-by: default avatarJens 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: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      dfe86cba
  22. 11 Aug, 2010 1 commit
  23. 24 Mar, 2010 1 commit
    • Adrian Hunter's avatar
      mmc: fix incorrect interpretation of card type bits · 7198f3c9
      Adrian Hunter authored
      In the extended CSD register the CARD_TYPE is an 8-bit value of which the
      upper 6 bits were reserved in JEDEC specifications prior to version 4.4.
      In version 4.4 two of the reserved bits were designated for identifying
      support for the newly added High-Speed Dual Data Rate.  Unfortunately the
      mmc_read_ext_csd() function required that the reserved bits be zero
      instead of ignoring them as it should.
      
      This patch makes mmc_read_ext_csd() ignore the CARD_TYPE bits that are
      reserved or not yet supported.  It also stops the function jumping to the
      end as though an error occurred, when it is only warns that the CARD_TYPE
      bits (that it does interpret) are invalid.
      Signed-off-by: default avatarAdrian Hunter <adrian.hunter@nokia.com>
      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>
      7198f3c9
  24. 23 Sep, 2009 2 commits
  25. 15 Jul, 2008 1 commit
  26. 23 Sep, 2007 1 commit
    • David Brownell's avatar
      MMC headers learn about SPI · 97018580
      David Brownell authored
      Teach the MMC/SD/SDIO system headers that some hosts use SPI mode
      
       - New host capabilities and status bits
          * MMC_CAP_SPI, with mmc_host_is_spi() test
          * mmc_host.use_spi_crc flag
      
       - SPI-specific declarations:
          * Response types, MMC_RSP_SPI_R*
          * Two SPI-only commands
          * Status bits used native to SPI:  R1_SPI_*, R2_SPI_*
      
       - Fix a few (unrelated) whitespace bugs in the headers.
      
       - Reorder a few mmc_host fields, removing several bytes of padding
      
      None of these changes affect current code.
      Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: default avatarPierre Ossman <drzeus@drzeus.cx>
      97018580