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 3 次提交
  3. 07 3月, 2010 1 次提交
  4. 23 9月, 2009 3 次提交
  5. 09 11月, 2008 1 次提交
  6. 27 7月, 2008 1 次提交
    • H
      mmc: Add per-card debugfs support · f4b7f927
      Haavard Skinnemoen 提交于
      For each card successfully added to the bus, create a subdirectory under
      the host's debugfs root with information about the card.
      
      At the moment, only a single file is added to the card directory for
      all cards: "state". It reflects the "state" field in struct mmc_card,
      indicating whether the card is present, readonly, etc.
      
      For MMC and SD cards (not SDIO), another file is added: "status".
      Reading this file will ask the card about its current status and
      return it. This can be useful if the card just refuses to respond to
      any commands, which might indicate that the card state is not what the
      MMC core thinks it is (due to a missing stop command, for example.)
      Signed-off-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>
      Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>
      f4b7f927
  7. 24 9月, 2007 5 次提交
  8. 01 5月, 2007 5 次提交
  9. 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
  10. 02 12月, 2006 2 次提交
    • 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
      [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
  11. 03 5月, 2006 1 次提交
  12. 04 1月, 2006 2 次提交
  13. 08 9月, 2005 3 次提交
    • P
      [PATCH] sd: SCR register · b57c43ad
      Pierre Ossman 提交于
      Read the SD specific SCR register from the card.
      Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: David Brownell <david-b@pacbell.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      b57c43ad
    • P
      [PATCH] sd: read-only switch · a00fc090
      Pierre Ossman 提交于
      Support for the read-only switch on SD cards which must be enforced by the
      host.
      Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: David Brownell <david-b@pacbell.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      a00fc090
    • P
      [PATCH] sd: initialize SD cards · 335eadf2
      Pierre Ossman 提交于
      Support for the Secure Digital protocol in the MMC layer.
      
      A summary of the legal issues surrounding SD cards, as understood by yours
      truly:
      
      Members of the Secure Digital Association, hereafter SDA, are required to sign
      a NDA[1] before given access to any specifications.  It has been speculated
      that including an SD implementation would forbid these members to redistribute
      Linux.  This is the basic problem with SD support so it is unclear if it even
      is a problem since it has no effect on those of us that aren't members.
      
      The SDA doesn't seem to enforce these rules though since the patches included
      here are based on documentation made public by some of the members.  The most
      complete specs[2] are actually released by Sandisk, one of the founding
      companies of the SDA.
      
      Because of this the NDA is considered a non-issue by most involved in the
      discussions concerning these patches.  It might be that the SDA is only
      interested in protecting the so called "secure" bits of SD, which so far
      hasn't been found in any public spec.  (The card is split into two sections,
      one "normal" and one "secure" which has an access scheme similar to TPM:s).
      
      (As a side note, Microsoft is working to make things easier for us since they
      want to be able to include the source code for a SD driver in one of their
      development kits.  HP is making sure that the new NDA will allow a Linux
      implementation.  So far only the SDIO specs have been opened up[3].  More will
      hopefully follow.)
      
       [1] http://www.sdcard.org/membership/images/ippolicy.pdf
       [2] http://www.sandisk.com/pdf/oem/ProdManualSDCardv1.9.pdf
       [3] http://www.sdcard.org/sdio/Simplified%20SDIO%20Card%20Specification.pdf
      
      This patch contains the central parts of the SD support.  If no MMC cards are
      found on a bus then the MMC layer proceeds looking for SD cards.  Helper
      functions are extended to handle the special needs of SD cards.
      Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: David Brownell <david-b@pacbell.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      335eadf2
  14. 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