1. 25 5月, 2011 2 次提交
  2. 16 3月, 2011 1 次提交
    • C
      mmc: export eMMC4.4 enhanced area details to sysfs · 709de99d
      Chuanxiao Dong 提交于
      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: NChuanxiao Dong <chuanxiao.dong@intel.com>
      Reviewed-by: NChris Ball <cjb@laptop.org>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      709de99d
  3. 09 1月, 2011 1 次提交
  4. 23 10月, 2010 1 次提交
  5. 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
  6. 11 8月, 2010 1 次提交
  7. 25 3月, 2010 1 次提交
    • A
      mmc: fix incorrect interpretation of card type bits · 7198f3c9
      Adrian Hunter 提交于
      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: NAdrian Hunter <adrian.hunter@nokia.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>
      7198f3c9
  8. 23 9月, 2009 2 次提交
  9. 15 7月, 2008 1 次提交
  10. 24 9月, 2007 1 次提交
    • D
      MMC headers learn about SPI · 97018580
      David Brownell 提交于
      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: NDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>
      97018580
  11. 23 9月, 2007 1 次提交
  12. 01 5月, 2007 3 次提交
  13. 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
  14. 02 12月, 2006 3 次提交
    • P
      mmc: Support for high speed SD cards · 7ccd266e
      Pierre Ossman 提交于
      Modern SD cards support a clock speed of 50 MHz. Make sure we test for
      this capability and do the song and dance required to activate it.
      
      Activating high speed support actually modifies the TRAN_SPEED field
      of the CSD. But as the spec says that the cards must report 50 MHz,
      we might as well skip re-reading the CSD.
      Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>
      7ccd266e
    • P
      mmc: Add support for mmc v4 wide-bus modes · e45a1bd2
      Philip Langdale 提交于
      This change adds support for the mmc4 4-bit wide-bus mode.
      
      The mmc4 spec defines 8-bit and 4-bit transfer modes. As we do not support
      any 8-bit hardware, this patch only adds support for the 4-bit mode, but
      it can easily be built upon when the time comes.
      
      The 4-bit mode is electrically compatible with SD's 4-bit mode but the
      procedure for turning it on is different. This patch implements only
      the essential parts of the procedure as defined by the spec. Two additional
      steps are recommended but not compulsory. I am documenting them here so
      that there's a record.
      
      1) A bus-test mechanism is implemented using dedicated mmc commands which allow
      for testing the functionality of the data bus at the electrical level. This is
      pretty paranoid and they way the commands work is not compatible with the mmc
      subsystem (they don't set valid CRC values).
      
      2) MMC v4 cards can indicate they would like to draw more than the default
      amount of current in wide-bus modes. We currently will never switch the card
      into a higher draw mode. Supposedly, allowing the card to draw more current
      will let it perform better, but the specs seem to indicate that the card will
      function correctly without the mode change. Empirical testing supports this
      interpretation.
      Signed-off-by: NPhilip Langdale <philipl@overt.org>
      Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>
      e45a1bd2
    • P
      [PATCH] mmc: Add support for mmc v4 high speed mode · bce40a36
      Philip Langdale 提交于
      This adds support for the high-speed modes defined by mmc v4
      (assuming the host controller is up to it). On a TI sdhci controller,
      it improves read speed from 1.3MBps to 2.3MBps. The TI controller can
      only go up to 24MHz, but everything helps. Another person has taken
      this basic patch and used it on a Nokia 770 to get a bigger boost
      because that controller can run at 48MHZ.
      Signed-off-by: NPhilip Langdale <philipl@overt.org>
      Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>
      bce40a36
  15. 06 10月, 2006 1 次提交
  16. 02 2月, 2006 1 次提交
  17. 29 11月, 2005 1 次提交
  18. 08 9月, 2005 1 次提交
  19. 21 5月, 2005 1 次提交
    • P
      [PATCH] MMC: Proper MMC command classes support · 912490db
      Pierre Ossman 提交于
      Defines for the different command classes as defined in the MMC and SD
      specifications.
      
      Removes the check for high command classes and instead checks that the
      command classes needed are present.
      Previous solution killed forward compatibility at no apparent gain.
      
      Signed-of-by: Pierre Ossman
      912490db
  20. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4