1. 29 Jan, 2015 1 commit
  2. 10 Nov, 2014 4 commits
  3. 18 Sep, 2014 1 commit
  4. 09 Sep, 2014 2 commits
  5. 12 May, 2014 4 commits
  6. 22 Apr, 2014 1 commit
  7. 17 Jan, 2014 1 commit
  8. 30 Oct, 2013 2 commits
    • Ulf Hansson's avatar
      mmc: Don't force card to active state when entering suspend/shutdown · 9ec775f7
      Ulf Hansson authored
      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: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarChris Ball <cjb@laptop.org>
      9ec775f7
    • Ulf Hansson's avatar
      mmc: core: Move cached value of the negotiated ocr mask to card struct · 69041150
      Ulf Hansson authored
      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: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarChris Ball <cjb@laptop.org>
      69041150
  9. 25 Sep, 2013 1 commit
  10. 27 Jun, 2013 1 commit
  11. 26 May, 2013 1 commit
  12. 22 Mar, 2013 1 commit
  13. 24 Feb, 2013 3 commits
  14. 11 Feb, 2013 1 commit
    • Konstantin Dorfman's avatar
      mmc: fix async request mechanism for sequential read scenarios · 2220eedf
      Konstantin Dorfman authored
      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: default avatarKonstantin Dorfman <kdorfman@codeaurora.org>
      Reviewed-by: default avatarSeungwon Jeon <tgih.jun@samsung.com>
      Signed-off-by: default avatarChris Ball <cjb@laptop.org>
      2220eedf
  15. 28 Jan, 2013 1 commit
    • Konstantin Dorfman's avatar
      mmc: fix async request mechanism for sequential read scenarios · 6035d973
      Konstantin Dorfman authored
      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: default avatarKonstantin Dorfman <kdorfman@codeaurora.org>
      Reviewed-by: default avatarSeungwon Jeon <tgih.jun@samsung.com>
      Signed-off-by: default avatarChris Ball <cjb@laptop.org>
      6035d973
  16. 06 Dec, 2012 1 commit
  17. 07 Oct, 2012 1 commit
  18. 03 Oct, 2012 1 commit
    • Jaehoon Chung's avatar
      mmc: support BKOPS feature for eMMC · 950d56ac
      Jaehoon Chung authored
      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: default avatarJaehoon Chung <jh80.chung@samsung.com>
      Signed-off-by: default avatarKyungmin Park <kyungmin.park@samsung.com>
      Signed-off-by: default avatarKonstantin Dorfman <kdorfman@codeaurora.org>
      Reviewed-by: default avatarMaya Erez <merez@codeaurora.org>
      Signed-off-by: default avatarChris Ball <cjb@laptop.org>
      950d56ac
  19. 04 Sep, 2012 1 commit
  20. 20 Jul, 2012 1 commit
  21. 09 May, 2012 1 commit
  22. 20 Apr, 2012 1 commit
  23. 25 Mar, 2012 1 commit
  24. 16 Mar, 2012 1 commit
    • Paul Gortmaker's avatar
      device.h: audit and cleanup users in main include dir · 313162d0
      Paul Gortmaker authored
      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: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      313162d0
  25. 13 Feb, 2012 1 commit
  26. 12 Jan, 2012 1 commit
  27. 11 Jan, 2012 4 commits