1. 25 2月, 2013 3 次提交
  2. 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
  3. 07 12月, 2012 1 次提交
  4. 08 10月, 2012 1 次提交
  5. 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
  6. 05 9月, 2012 1 次提交
  7. 21 7月, 2012 1 次提交
  8. 09 5月, 2012 1 次提交
  9. 21 4月, 2012 1 次提交
  10. 26 3月, 2012 1 次提交
  11. 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
  12. 14 2月, 2012 1 次提交
  13. 13 1月, 2012 1 次提交
  14. 12 1月, 2012 4 次提交
  15. 11 12月, 2011 1 次提交
  16. 27 10月, 2011 9 次提交
  17. 21 7月, 2011 1 次提交
  18. 14 7月, 2011 1 次提交
  19. 26 5月, 2011 2 次提交
  20. 25 5月, 2011 7 次提交