1. 31 10月, 2013 2 次提交
    • U
      mmc: Don't force card to active state when entering suspend/shutdown · 9ec775f7
      Ulf Hansson 提交于
      By adding a card state that records if it is suspended or resumed, we
      can accept asyncronus suspend/resume requests for the mmc and sd
      bus_ops.
      
      MMC_CAP_AGGRESSIVE_PM, will at request inactivity through the runtime
      bus_ops callbacks, execute a suspend of the the card. In the state were
      this has been done, we can receive a suspend request for the mmc bus,
      which for sd and mmc forced the card to active state by a
      pm_runtime_get_sync. In other words, the card was resumed and then
      immediately suspended again, completely unnecessary.
      
      Since the suspend/resume bus_ops callbacks for sd and mmc are now
      capable of handling asynchronous requests, we no longer need to force
      the card to active state before executing suspend. Evidently preventing
      the above sequence for MMC_CAP_AGGRESSIVE_PM.
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      9ec775f7
    • U
      mmc: core: Move cached value of the negotiated ocr mask to card struct · 69041150
      Ulf Hansson 提交于
      The negotiated ocr mask is directly related to the card. Once a card
      gets removed, the mask shall be dropped. By moving the cache of the ocr
      mask from the host struct to the card struct we have accomplished this.
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      69041150
  2. 26 9月, 2013 1 次提交
  3. 28 6月, 2013 1 次提交
  4. 27 5月, 2013 1 次提交
  5. 23 3月, 2013 1 次提交
  6. 25 2月, 2013 3 次提交
  7. 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
  8. 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
  9. 07 12月, 2012 1 次提交
  10. 08 10月, 2012 1 次提交
  11. 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
  12. 05 9月, 2012 1 次提交
  13. 21 7月, 2012 1 次提交
  14. 09 5月, 2012 1 次提交
  15. 21 4月, 2012 1 次提交
  16. 26 3月, 2012 1 次提交
  17. 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
  18. 14 2月, 2012 1 次提交
  19. 13 1月, 2012 1 次提交
  20. 12 1月, 2012 4 次提交
  21. 11 12月, 2011 1 次提交
  22. 27 10月, 2011 9 次提交
  23. 21 7月, 2011 1 次提交
  24. 14 7月, 2011 1 次提交
  25. 26 5月, 2011 2 次提交