1. 02 10月, 2010 3 次提交
    • K
      omap4 hsmmc: Update ocr mask for MMC2 for regulator to use · 64be9782
      kishore kadiyala 提交于
      On OMAP4, MMC2 controller has eMMC which draws power from VAUX regulator
      on TWL. Though the eMMC supports dual voltage[1.8v/3v] as per ocr register,
      its VCC is fixed at 3V for operation. With this once the mmc core selects
      the minimum voltage[1.8] supported based on the ocr value read from OCR register,
      eMMC will not get detected. Thus the platform data for MMC2 is updated with ocr
      mask and same will be communicated to core which will set the regulator to
      always operate at 3V when ever turned ON.
      
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Madhusudhan Chikkature <madhu.cr@ti.com>
      Cc: Adrian Hunter <adrian.hunter@nokia.com>
      Signed-off-by: NKishore Kadiyala <kishore.kadiyala@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      64be9782
    • K
      omap4 hsmmc: Register offset handling · 91a0b089
      kishore kadiyala 提交于
      In OMAP4, as per new PM programming model, the legacy registers
      which were there in OMAP3 are all shifted by 0x100 while new one's
      are added from offset 0 to 0x10.
      For OMAP4, the register offset appending of 0x100 done in devices.c
      currently, is moved to driver file.This change fits in for current
      implementation as well as once the driver undergoes hwmod adaptation.
      
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Madhusudhan Chikkature <madhu.cr@ti.com>
      Cc: Adrian Hunter <adrian.hunter@nokia.com>
      Cc: Benoit Cousson <b-cousson@ti.com>
      Signed-off-by: NKishore Kadiyala <kishore.kadiyala@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      91a0b089
    • M
      OMAP4 ES2: HSMMC soft reset change · 07ad64b6
      Madhusudhan Chikkature 提交于
      The omap4 es2 hsmmc has a updated soft reset logic.After the
      reset is issued monitor a 0->1 transition first. The reset of
      CMD or DATA lines is complete only after a 0->1->0 transition
      of SRC or SRD bits.
      Signed-off-by: NMadhusudhan Chikkature <madhu.cr@ti.com>
      Tested-by: NAnand Gadiyar <gadiyar@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      07ad64b6
  2. 28 9月, 2010 1 次提交
  3. 10 9月, 2010 8 次提交
  4. 21 8月, 2010 3 次提交
  5. 19 8月, 2010 1 次提交
  6. 12 8月, 2010 6 次提交
    • A
      mmc_test: fix large memory allocation · fec4dcce
      Adrian Hunter 提交于
      - Fix mmc_test_alloc_mem.
      
      - Use nr_free_buffer_pages() instead of sysinfo.totalram to determine
        total lowmem pages.
      
      - Change variables containing memory sizes to unsigned long.
      
      - Limit maximum test area size to 128MiB because that is the maximum MMC
        high capacity erase size (the maxmium SD allocation unit size is just
        4MiB)
      Signed-off-by: NAdrian Hunter <adrian.hunter@nokia.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      fec4dcce
    • A
      mmc_test: add performance tests · 64f7120d
      Adrian Hunter 提交于
      mmc_test provides tests aimed at testing SD/MMC hosts.  This patch adds
      performance tests.
      
      It is advantageous to have performance tests in a kernel
      module like mmc_test for the following reasons:
      	- transfer times can be measured very accurately
      	- arbitrarily large transfers are possible
      	- the effect of contiguous vs scattered pages
      	can be determined
      
      The new tests are:
      
      	23. Best-case read performance
      	24. Best-case write performance
      	25. Best-case read performance into scattered pages
      	26. Best-case write performance from scattered pages
      	27. Single read performance by transfer size
      	28. Single write performance by transfer size
      	29. Single trim performance by transfer size
      	30. Consecutive read performance by transfer size
      	31. Consecutive write performance by transfer size
      	32. Consecutive trim performance by transfer size
      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>
      64f7120d
    • A
      mmc_block: add support for secure discard · 49804548
      Adrian Hunter 提交于
      Secure discard is implemented by Secure Trim if the discard is unaligned
      or Secure Erase otherwise.
      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>
      49804548
    • A
      omap_hsmmc: add erase capability · 93caf8e6
      Adrian Hunter 提交于
      Disable the data (busy) timeout for erases and set the MMC_CAP_ERASE
      capability.
      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>
      93caf8e6
    • A
      mmc_block: add discard support · bd788c96
      Adrian Hunter 提交于
      Enable MMC to service discard requests.  In the case of SD and MMC cards
      that do not support trim, discards become erases.  In the case of cards
      (MMC) that only allow erases in multiples of erase group size, round to
      the nearest completely discarded erase group.
      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>
      bd788c96
    • 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
  7. 11 8月, 2010 18 次提交