1. 28 6月, 2013 5 次提交
  2. 27 6月, 2013 1 次提交
  3. 27 5月, 2013 5 次提交
    • F
      mmc: core: Fix select power class after resume · 60443712
      Fredrik Soderstedt 提交于
      Use the saved values in card->ext_csd when selecting power class.
      By doing this the power class will be selected even if mmc_init_card
      is called with oldcard != NULL, which is the case after a suspend/resume.
      
      Today ext_csd is NULL if mmc_init_card is called with oldcard != NULL
      and power class will not be selected.
      
      According to the eMMC specification the POWER_CLASS value is reset after
      power failure, H/W reset assertion and any CMD0 reset.
      Signed-off-by: NFredrik Soderstedt <fredrik.soderstedt@stericsson.com>
      Reviewed-by: NJohan Rudholm <jrudholm@gmail.com>
      Acked By: Girish K S <girish.shivananjappa@linaro.org>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      60443712
    • U
      mmc: core: Restructure and simplify code for mmc sleep|awake · 07a68216
      Ulf Hansson 提交于
      The mmc_card_sleep|awake APIs are not being used since the support is
      already properly encapsulated within the suspend sequence. Sleep|awake
      command is also specific for eMMC.
      
      We remove the sleep|awake bus_ops, the mmc_card_sleep|awake APIs and
      move the code into the mmc specific core instead. This also includes
      the mmc ops function, mmc_sleepawake. All releated functions have then
      become static and we have got far less code to maintain.
      
      Additionally this patch also simplifies the code from mmc_sleepawake,
      since it is only used to put the card to sleep and not awake.
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      07a68216
    • U
      mmc: core: Support aggressive power management for (e)MMC/SD · c4d770d7
      Ulf Hansson 提交于
      Aggressive power management is suitable when saving power is
      essential. At request inactivity timeout, aka pm runtime
      autosuspend timeout, the card will be suspended.
      
      Once a new request arrives, the card will be re-initalized and
      thus the first request will suffer from a latency. This latency
      is card-specific, experiments has shown in general that SD-cards
      has quite poor initialization time, around 300ms-1100ms. eMMC is
      not surprisingly far better but still a couple of hundreds of ms
      has been observed.
      
      Except for the request latency, it is important to know that
      suspending the card will also prevent the card from executing
      internal house-keeping operations in idle mode. This could mean
      degradation in performance.
      
      To use this feature make sure the request inactivity timeout is
      chosen carefully. This has not been done as a part of this patch.
      
      Enable this feature by using host cap MMC_CAP_AGGRESSIVE_PM and
      by setting CONFIG_MMC_UNSAFE_RESUME.
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      c4d770d7
    • 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
    • U
      mmc: core: Stop bkops for eMMC only from mmc suspend · 39b9431b
      Ulf Hansson 提交于
      Move mmc suspend specific operations to be executed from the .suspend
      callback in the mmc bus_ops. This simplifies the mmc_suspend_host
      function which is supposed to handle nothing but common suspend tasks.
      
      Since eMMC can be considered non-removable there are no need to check
      for ongoing bkops at PM_SUSPEND_PREPARE notification so remove it.
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      39b9431b
  4. 05 4月, 2013 1 次提交
  5. 23 3月, 2013 1 次提交
  6. 25 2月, 2013 4 次提交
  7. 07 12月, 2012 4 次提交
  8. 08 10月, 2012 1 次提交
  9. 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
  10. 23 7月, 2012 1 次提交
    • A
      mmc: core: reset signal voltage on power up · 108ecc4c
      Aaron Lu 提交于
      Add a call to mmc_set_signal_voltage() to set signal voltage to 3.3v in
      mmc_power_up so that we do not need to touch signal voltage setting in
      mmc/sd/sdio init functions and rescan function.
      
      For mmc/sd cards, when doing a suspend/resume cycle, consider the unsafe
      resume case, the card will lose its power and when powered on again, we
      will set signal voltage to 3.3v in mmc_power_up before its resume function
      gets called, which will re-init the card.
      
      And for sdio cards, when doing a suspend/resume cycle, consider the unsafe
      resume case, the card will either lose its power or not depending on if it
      wants to wakeup the host. If power is not maintained, it is the same case as
      mmc/sd cards. If power is maintained, mmc_power_up will not be called and
      the card's signal voltage will remain at the last setting.
      Signed-off-by: NAaron Lu <aaron.lu@amd.com>
      Tested-by: NVenkatraman S <svenkatr@ti.com>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      108ecc4c
  11. 11 7月, 2012 1 次提交
  12. 06 6月, 2012 1 次提交
  13. 17 5月, 2012 1 次提交
  14. 10 5月, 2012 1 次提交
  15. 09 5月, 2012 3 次提交
  16. 06 4月, 2012 1 次提交
  17. 28 3月, 2012 2 次提交
  18. 26 3月, 2012 1 次提交
  19. 05 3月, 2012 1 次提交
  20. 14 2月, 2012 3 次提交
  21. 13 1月, 2012 1 次提交