1. 26 10月, 2015 1 次提交
  2. 18 6月, 2015 1 次提交
  3. 08 4月, 2015 1 次提交
  4. 19 1月, 2015 1 次提交
  5. 08 12月, 2014 1 次提交
  6. 26 11月, 2014 1 次提交
  7. 10 11月, 2014 2 次提交
  8. 23 2月, 2014 2 次提交
  9. 31 10月, 2013 1 次提交
  10. 26 9月, 2013 1 次提交
  11. 26 8月, 2013 1 次提交
  12. 27 5月, 2013 2 次提交
    • U
      mmc: block: Enable runtime pm for mmc blkdevice · e94cfef6
      Ulf Hansson 提交于
      Once the mmc blkdevice is being probed, runtime pm will be enabled.
      By using runtime autosuspend, the power save operations can be done
      when request inactivity occurs for a certain time. Right now the
      selected timeout value is set to 3 s. Obviously this value will likely
      need to be configurable somehow since it needs to be trimmed depending
      on the power save algorithm.
      
      For SD-combo cards, we are still leaving the enablement of runtime PM
      to the SDIO init sequence since it depends on the capabilities of the
      SDIO func driver.
      
      Moreover, when the blk device is being suspended, we make sure the device
      will be runtime resumed. The reason for doing this is that we want the
      host suspend sequence to be unaware of any runtime power save operations
      done for the card in this phase. Thus it can just handle the suspend as
      the card is fully powered from a runtime perspective.
      
      Finally, this patch prepares to make it possible to move BKOPS handling
      into the runtime callbacks for the mmc bus_ops. Thus IDLE BKOPS can be
      accomplished.
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      e94cfef6
    • M
      mmc: card: Adding support for sanitize in eMMC 4.5 · 775a9362
      Maya Erez 提交于
      The sanitize support is added as a user-app ioctl call, and
      was removed from the block-device request, since its purpose is
      to be invoked not via File-System but by a user.
      
      This feature deletes the unmap memory region of the eMMC card,
      by writing to a specific register in the EXT_CSD.
      
      unmap region is the memory region that was previously deleted
      (by erase, trim or discard operation).
      
      In order to avoid timeout when sanitizing large-scale cards,
      the timeout for sanitize operation is 240 seconds.
      Signed-off-by: NYaniv Gardi <ygardi@codeaurora.org>
      Signed-off-by: NMaya Erez <merez@codeaurora.org>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      775a9362
  13. 25 2月, 2013 1 次提交
    • S
      mmc: support packed write command for eMMC4.5 devices · ce39f9d1
      Seungwon Jeon 提交于
      This patch supports packed write command of eMMC4.5 devices.  Several
      writes can be grouped in packed command and all data of the individual
      commands can be sent in a single transfer on the bus. Large amounts of
      data in one transfer rather than several data of small size are
      effective for eMMC write internally.  As a result, packed command help
      write throughput be improved.  The following tables show the results
      of packed write.
      
      Type A:
      test     none |  packed
      iozone   25.8 |  31
      tiotest  27.6 |  31.2
      lmdd     31.2 |  35.4
      
      Type B:
      test     none |  packed
      iozone   44.1 |  51.1
      tiotest  47.9 |  52.5
      lmdd     51.6 |  59.2
      
      Type C:
      test     none |  packed
      iozone   19.5 |  32
      tiotest  19.9 |  34.5
      lmdd     22.8 |  40.7
      Signed-off-by: NSeungwon Jeon <tgih.jun@samsung.com>
      Reviewed-by: NMaya Erez <merez@codeaurora.org>
      Reviewed-by: NNamjae Jeon <linkinjeon@gmail.com>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      ce39f9d1
  14. 12 2月, 2013 1 次提交
    • K
      mmc: fix async request mechanism for sequential read scenarios · 2220eedf
      Konstantin Dorfman 提交于
      When current request is running on the bus and if next request fetched
      by mmcqd is NULL, mmc context (mmcqd thread) gets blocked until the
      current request completes. This means that if new request comes in while
      the mmcqd thread is blocked, this new request can not be prepared in
      parallel to current ongoing request. This may result in delaying the new
      request execution and increase it's latency.
      
      This change allows to wake up the MMC thread on new request arrival.
      Now once the MMC thread is woken up, a new request can be fetched and
      prepared in parallel to the current running request which means this new
      request can be started immediately after the current running request
      completes.
      
      With this change read throughput is improved by 16%.
      Signed-off-by: NKonstantin Dorfman <kdorfman@codeaurora.org>
      Reviewed-by: NSeungwon Jeon <tgih.jun@samsung.com>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      2220eedf
  15. 28 1月, 2013 1 次提交
    • K
      mmc: fix async request mechanism for sequential read scenarios · 6035d973
      Konstantin Dorfman 提交于
      When current request is running on the bus and if next request fetched
      by mmcqd is NULL, mmc context (mmcqd thread) gets blocked until the
      current request completes. This means that if new request comes in while
      the mmcqd thread is blocked, this new request can not be prepared in
      parallel to current ongoing request. This may result in delaying the new
      request execution and increase it's latency.
      
      This change allows to wake up the MMC thread on new request arrival.
      Now once the MMC thread is woken up, a new request can be fetched and
      prepared in parallel to the current running request which means this new
      request can be started immediately after the current running request
      completes.
      
      With this change read throughput is improved by 16%.
      Signed-off-by: NKonstantin Dorfman <kdorfman@codeaurora.org>
      Reviewed-by: NSeungwon Jeon <tgih.jun@samsung.com>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      6035d973
  16. 07 12月, 2012 1 次提交
  17. 03 10月, 2012 1 次提交
    • J
      mmc: support BKOPS feature for eMMC · 950d56ac
      Jaehoon Chung 提交于
      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: NJaehoon Chung <jh80.chung@samsung.com>
      Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
      Signed-off-by: NKonstantin Dorfman <kdorfman@codeaurora.org>
      Reviewed-by: NMaya Erez <merez@codeaurora.org>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      950d56ac
  18. 28 3月, 2012 1 次提交
  19. 16 3月, 2012 1 次提交
    • P
      device.h: audit and cleanup users in main include dir · 313162d0
      Paul Gortmaker 提交于
      The <linux/device.h> header includes a lot of stuff, and
      it in turn gets a lot of use just for the basic "struct device"
      which appears so often.
      
      Clean up the users as follows:
      
      1) For those headers only needing "struct device" as a pointer
      in fcn args, replace the include with exactly that.
      
      2) For headers not really using anything from device.h, simply
      delete the include altogether.
      
      3) For headers relying on getting device.h implicitly before
      being included themselves, now explicitly include device.h
      
      4) For files in which doing #1 or #2 uncovers an implicit
      dependency on some other header, fix by explicitly adding
      the required header(s).
      
      Any C files that were implicitly relying on device.h to be
      present have already been dealt with in advance.
      
      Total removals from #1 and #2: 51.  Total additions coming
      from #3: 9.  Total other implicit dependencies from #4: 7.
      
      As of 3.3-rc1, there were 110, so a net removal of 42 gives
      about a 38% reduction in device.h presence in include/*
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      313162d0
  20. 12 1月, 2012 1 次提交
  21. 27 10月, 2011 5 次提交
  22. 21 7月, 2011 3 次提交
  23. 26 5月, 2011 1 次提交
  24. 25 5月, 2011 3 次提交
  25. 18 3月, 2011 1 次提交
  26. 23 10月, 2010 2 次提交
  27. 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
  28. 23 9月, 2009 1 次提交