1. 22 4月, 2014 2 次提交
    • S
      mmc: core: Use maximum timeout values in case TACC field is zero · f7bf11a3
      Stefan Wahren 提交于
      When plugging a specific micro SD card at MMC socket of a custom i.MX28 board,
      we get the following kernel warning:
      
      WARNING: CPU: 0 PID: 30 at drivers/mmc/host/mxs-mmc.c:342 mxs_mmc_start_cmd+0x34c/0x378()
      Modules linked in:
      CPU: 0 PID: 30 Comm: kworker/u2:1 Not tainted 3.14.0-rc5 #8
      Workqueue: kmmcd mmc_rescan
      [<c0015420>] (unwind_backtrace) from [<c0012cb0>] (show_stack+0x10/0x14)
      [<c0012cb0>] (show_stack) from [<c001daf8>] (warn_slowpath_common+0x6c/0x8c)
      [<c001daf8>] (warn_slowpath_common) from [<c001db34>] (warn_slowpath_null+0x1c/0x24)
      [<c001db34>] (warn_slowpath_null) from [<c0349478>] (mxs_mmc_start_cmd+0x34c/0x378)
      [<c0349478>] (mxs_mmc_start_cmd) from [<c0338fa0>] (mmc_start_request+0xc4/0xf4)
      [<c0338fa0>] (mmc_start_request) from [<c03390b4>] (mmc_wait_for_req+0x50/0x164)
      [<c03390b4>] (mmc_wait_for_req) from [<c03405b8>] (mmc_app_send_scr+0x158/0x1c8)
      [<c03405b8>] (mmc_app_send_scr) from [<c033ee1c>] (mmc_sd_setup_card+0x80/0x3c8)
      [<c033ee1c>] (mmc_sd_setup_card) from [<c033f788>] (mmc_sd_init_card+0x124/0x66c)
      [<c033f788>] (mmc_sd_init_card) from [<c033fd7c>] (mmc_attach_sd+0xac/0x174)
      [<c033fd7c>] (mmc_attach_sd) from [<c033a658>] (mmc_rescan+0x25c/0x2d8)
      [<c033a658>] (mmc_rescan) from [<c003597c>] (process_one_work+0x1b4/0x4ec)
      [<c003597c>] (process_one_work) from [<c0035de4>] (worker_thread+0x130/0x464)
      [<c0035de4>] (worker_thread) from [<c003c824>] (kthread+0xb4/0xd0)
      [<c003c824>] (kthread) from [<c000f420>] (ret_from_fork+0x14/0x34)
      
      The error is due to an invalid value in CSD register of a specific 2GB
      micro SD card. The CSD version of this card is 1.0 but the TACC field
      has the invalid value 0.
      
      cid:0000005553442020000000000000583f
      csd:00000032535a83bfedb7ffbf1680003f
      date:08/2005
      erase_size:512
      fwrev:0x0
      hwrev:0x0
      manfid:0x000000
      name:USD
      oemid:0x0000
      preferred_erase_size:4194304
      scr:0225000000000000
      serial:0x00000000
      type:SD
      
      Since the kernel is making use of this TACC field to calculate the SD
      card timeout, an invalid value 0 leads to a warning at
      mxs_ns_to_ssp_ticks() and later the following misleading error message
      appears in a loop:
      
      mxs-mmc 80010000.ssp: card claims to support voltages below defined range
      mxs-mmc 80010000.ssp: no support for card's volts
      mmc0: error -22 whilst initialising MMC card
      
      This error is only found on this 2GB SD card on mxs platform.
      On x86 this card works without any problems.
      
      The following patch based on the work of Peter Chan and Otavio Salvador.
      It catches the case that the determined timeout is still 0 and sets it
      to a valid value.
      
      Successful tested on a i.MX28 board.
      Signed-off-by: NStefan Wahren <stefan.wahren@i2se.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: NChris Ball <chris@printf.net>
      f7bf11a3
    • M
      mmc: Delay the card_event callback into the mmc_rescan worker · fa372a51
      Markus Mayer 提交于
      This change removes the callback from atomic context which it doesn't
      need to be in, and puts it in line with the debounced rescan.
      
      This code is based on these e-mail threads with Christian Daudt:
      
        https://lkml.org/lkml/2013/8/19/539
        https://lkml.org/lkml/2014/3/19/79Signed-off-by: NMarkus Mayer <markus.mayer@linaro.org>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: NChris Ball <chris@printf.net>
      fa372a51
  2. 17 3月, 2014 1 次提交
  3. 23 2月, 2014 3 次提交
  4. 14 2月, 2014 4 次提交
  5. 14 1月, 2014 1 次提交
  6. 31 10月, 2013 8 次提交
  7. 26 9月, 2013 1 次提交
  8. 26 8月, 2013 1 次提交
  9. 31 7月, 2013 1 次提交
  10. 28 6月, 2013 4 次提交
  11. 27 5月, 2013 6 次提交
    • 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: 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
  12. 30 4月, 2013 1 次提交
  13. 15 4月, 2013 1 次提交
  14. 13 4月, 2013 2 次提交
  15. 23 3月, 2013 2 次提交
    • 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
    • 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
  16. 25 2月, 2013 2 次提交