1. 28 6月, 2013 12 次提交
  2. 27 6月, 2013 2 次提交
  3. 27 5月, 2013 9 次提交
    • 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: Add bus_ops for runtime pm callbacks · 12d01d0b
      Ulf Hansson 提交于
      SDIO is the only protocol that uses runtime pm for the card device
      right now. To provide the option for sd and mmc to use runtime pm as
      well the bus_ops callback are extended with two new functions. One for
      runtime_suspend and one for runtime_resume.
      
      This patch will also implement the callbacks for SDIO to make sure
      existing functionality is maintained. It also prepares to move
      away from using the mmc_power_restore_host API, since it is not
      needed when using runtime PM.
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      12d01d0b
    • 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
    • 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
    • U
      mmc: core: Re-use code for MMC_CAP2_DETECT_ON_ERR in polling mode · b6891679
      Ulf Hansson 提交于
      Previously the MMC_CAP2_DETECT_ON_ERR was invented for detecting
      slow card removal. In was never a realy good solution and a proper
      fix has been merged using gpio debouncing instead. We remove this
      cap in this patch.
      
      Although when using polling card detect mode, the code invented for
      MMC_CAP2_DETECT_ON_ERR is re-used to complete card removal in an
      earlier phase. There are no need waiting for the polling timeout to
      elapse in this case.
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      Reviewed-by: NKevin Liu <kliu5@marvell.com>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      b6891679
    • F
      mmc: core: Only execute tuning for SDR50 and SDR104 · 810e08ee
      Fredrik Soderstedt 提交于
      Only execute tuning for sd and sdio devices that are using
      SDR50 or SDR104.
      
      Make sure clock is hold during tuning for sdio devices.
      Signed-off-by: NFredrik Soderstedt <fredrik.soderstedt@stericsson.com>
      Acked-by: NJohan Rudholm <jrudholm@gmail.com>
      Acked-by: NUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      810e08ee
  4. 30 4月, 2013 1 次提交
  5. 15 4月, 2013 1 次提交
  6. 13 4月, 2013 3 次提交
  7. 05 4月, 2013 1 次提交
  8. 23 3月, 2013 4 次提交
    • S
      mmc: core: wait while adding MMC host to ensure root mounts successfully · 3500ed90
      Sergey Yanovich 提交于
      MMC hosts are added asynchronously. We need to wait until detect returns to
      avoid failed root filesystem mounts.
      
      VFS: Cannot open root device "mmcblk0p1" or unknown-block(0,0): error -6
      Please append a correct "root=" boot option; here are the available partitions:
      mmc0: host does not support reading read-only switch. assuming write-enable.
      1f00             256 mtdblock0  (driver?)
      1f01             256 mtdblock1  (driver?)
      1f02            2560 mtdblock2 mmc0: new SDHC card at address b368
       (driver?)
      1f03           29696 mtdblock3  (driver?)
      1f04           16384 mtdblock4 mmcblk0: mmc0:b368 USD   3.72 GiB
       (driver?)
       mmcblk0: p1
      b300         3910656 mmcblk0  driver: mmcblk
        b301         3906560 mmcblk0p1 00000000-01
      Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
      Signed-off-by: NSergey Yanovich <ynvich@gmail.com>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      3500ed90
    • A
      mmc: sdio: bind acpi with sdio function device · eed222ac
      Aaron Lu 提交于
      ACPI spec 5 defined the _ADR encoding for sdio bus as:
      High word - slot number (0 based)
      Low word  - function number
      
      This patch adds support for binding sdio function device with acpi node,
      and if successful, involve acpi into its power management.
      Signed-off-by: NAaron Lu <aaron.lu@intel.com>
      Reviewed-by: NAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      eed222ac
    • K
      mmc: core: enhance card removal judgement for slow removal · 1450734e
      Kevin Liu 提交于
      Function _mmc_detect_card_removed will be called to know whether
      the card is still present when host->bus_ops->detect is called.
      In current code, the return value of this function generally only
      depend on the result of sending cmd13 to card, which may not safe
      for card with detection support like slot gpio detection.
      Because the communication status between host and card may out of
      sync with the detect status if remove the card slowly or hands shake
      during the process. The direct reason is the async between card
      detect switch and card/slot pad contaction in hardware, which is
      defined by spec.
      
      The spec define card insert/remove sequence as below (both standard size
      SD card and MicroSD card have the same sequence):
      "Part 1 Standard Size SD Card Mechanical Addendum Ver4.00 Final,
      Appendix C: Card Detection Switch" (Take normally open type as example)
      a)SD card insertion sequence:
        The card detection switch should be turned on after all SD card
        contact pads are connected to the host connector contact pads.
      b)SD removal sequence:
        The card detection switch should be turned off when the SD card
        is just going to be removed and before any SD card contact pad is
        disconnected from the host connector contact pad.
      
      Below is the sequence when this issue occur (Take slot gpio detection
      as example and remove the card slowly during the process):
      1. gpio level changed and card detect interrupt triggered.
      2. mmc_rescan was launched.
      3. the card pads were still contacted with the slot pads because of slow
         removal. So _mmc_detect_card_removed and mmc_rescan think card was
         still present (cmd13 succeed).
      4. card pads were discontacted from the card slot pads.
      So the card was actually removed finally but the card removal event
      has been missed by system.
      The interval length between step 1 and step 4 depends on the
      card removal speed. If it's longer than the detect work schedule
      delay which is 200ms, this issue will likely happen.
      
      This patch add the card detect status check in function
      _mmc_detect_card_removed if cmd13 check succeed and host->ops->get_cd
      provided. If get_cd detect no card present then schedule another detect
      work 200ms later.
      Signed-off-by: NKevin Liu <kliu5@marvell.com>
      Tested-by: NJohan Rudholm <johan.rudholm@stericsson.com>
      Reviewed-by: NPhilip Rakity <prakity@nvidia.com>
      Acked-by: NUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      1450734e
    • B
      mmc: core: Add in support to expose PRV for v4 MMCs · 51e7e8b6
      Bernie Thompson 提交于
      The JEDEC MMC v4 spec defines a new PRV value in place of the original
      fwrev and hwrev specified in v1. We can expose this in the kernel to enable
      user space to more easily determine the product revision of a given MMC.
      Signed-off-by: NBernie Thompson <bhthompson@chromium.org>
      Reviewed-by: NUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      51e7e8b6
  9. 28 2月, 2013 1 次提交
  10. 25 2月, 2013 6 次提交