1. 26 11月, 2014 2 次提交
    • V
      mmc: core: hold SD Clock before CMD11 during Signal · c6eb5880
      Vincent Yang 提交于
      Voltage Switch Procedure
      
      This patch is to fix an issue found on mb86s7x platforms.
      
      [symptom]
      There are some UHS-1 SD memory cards sometimes cannot be detected correctly,
      e.g., Transcend 600x SDXC 64GB UHS-1 memory card.
      During Signal Voltage Switch Procedure, failure to switch is indicated
      by the card holding DAT[3:0] low.
      
      [analysis]
      According to SD Host Controller Simplified Specification Version 3.00
      chapter 3.6.1, the Signal Voltage Switch Procedure should be:
      (1) Check S18A; (2) Issue CMD11; (3) Check CMD 11 response;
      (4) Stop providing SD clock; (5) Check DAT[3:0] should be 0000b;
      (6) Set 1.8V Signal Enable; (7) Wait 5ms; (8) Check 1.8V Signal Enable;
      (9) Provide SD Clock; (10) Wait 1ms; (11) Check DAT[3:0] should be 1111b;
      (12) error handling
      
      With CONFIG_MMC_CLKGATE=y, sometimes there is one more gating/un-gating
      SD clock between (2) and (3). In this case, some UHS-1 SD cards will hold
      DAT[3:0] 0000b at (11) and thus fails Signal Voltage Switch Procedure.
      
      [solution]
      By mmc_host_clk_hold() before CMD11, the additional gating/un-gating
      SD clock between (2) and (3) can be prevented and thus no failure at (11).
      It has been verified with many UHS-1 SD cards on mb86s7x platforms and
      works correctly.
      Signed-off-by: NVincent Yang <Vincent.Yang@tw.fujitsu.com>
      Reviewed-by: NJohan Rudholm <jrudholm@gmail.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      c6eb5880
    • J
      mmc: core: consistent handling of initial values · 2d079c43
      Johan Rudholm 提交于
      mmc_do_hw_reset(), mmc_power_up() and mmc_power_off() all set similar
      initial values for bus_mode, bus_width, chip_select and timing. Let's
      make this handling simpler and more consistent by sticking them
      together in a common function. This will introduce small changes in
      behavior in the following places:
      
      mmc_power_off():
      
        For SPI hosts, explicitly set bus_mode = MMC_BUSMODE_PUSHPULL and
        chip_select = MMC_CS_HIGH, before we left them as they were.
      
        For non-SPI hosts, set bus_mode = MMC_BUSMODE_PUSHPULL instead of
        MMC_BUSMODE_OPENDRAIN as before.
      
        These two changes should not be a problem since the device will be
        powered off anyway.
      
      mmc_do_hw_reset():
      
        Always set bus_mode = MMC_BUSMODE_PUSHPULL, as required by SD/SDIO
        cards. MMC cards require MMC_BUSMODE_OPENDRAIN, but this is taken
        care of by mmc_init_card() and mmc_attach_mmc().
      Signed-off-by: NJohan Rudholm <johanru@axis.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      2d079c43
  2. 10 11月, 2014 5 次提交
    • J
      ad89fcb2
    • U
      mmc: core: Use mmc_get_ext_csd() instead of mmc_send_ext_csd() · b2cada73
      Ulf Hansson 提交于
      By using mmc_get_ext_csd() in favor of mmc_send_ext_csd, we decrease
      code duplication.
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      b2cada73
    • S
      mmc: core: fix prepared requests while doing bkops · 64b12a68
      Srinivas Kandagatla 提交于
      While starting the bkops the previously prepared request should be canceled
      and restarted after the bkops. As the prepared resource might already
      setup the dma channels and ready to be started. Now with the arrival of bkops
      request this prepared request can be serviced ONLY after the bkops. So
      holding on to the prepared request in the host driver is confusing at
      this point in time, so it makes sense to cleanup such dangling requests and
      reissue this request once bkops is done.
      Canceling the prepared request would give opportunity to the host drivers
      to perform cleanup on the prepared request.
      
      Without this patch host drivers like mmci gets confused when a blocking
      request like send_ext_csd(CMD8) is issued while there is already a prepared
      request. With the help of this patch, the driver can better manage such
      blocking requests and cleanup the prepared requests which are not started yet.
      
      Without this patch I hit below crash on Qualcomm APQ8064 based IFC6410 board
      with mmci host driver.
      
      mmci-pl18x 12400000.sdcc: error during DMA transfer!
      Unable to handle kernel paging request at virtual address 40000000
      pgd = c0204000
      [40000000] *pgd=00000000
      Internal error: Oops: 805 [#1] SMP ARM
      Modules linked in: ipv6 ath6kl_sdio ath6kl_core
      CPU: 0 PID: 0 Comm: swapper/0 Tainted: G        W      3.17.0-rc7-linaro-multi-v7 #1
      task: c0c9d7e0 ti: c0c92000 task.ti: c0c92000
      PC is at v7_dma_inv_range+0x34/0x4c
      LR is at __dma_page_dev_to_cpu+0x80/0x100
      pc : [<c021efc0>]    lr : [<c021af18>]    psr: 400f0193
      sp : c0c93e20  ip : c0c9a478  fp : c08ea538
      r10: c0c9f548  r9 : 00000002  r8 : e97d9000
      r7 : 00000200  r6 : c0c9d504  r5 : c0db0880  r4 : 00000000
      r3 : 0000003f  r2 : 00000040  r1 : 40000200  r0 : 40000000
      Flags: nZcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
      Control: 10c5787d  Table: a9ef406a  DAC: 00000015
      Process swapper/0 (pid: 0, stack limit = 0xc0c92250)
      Stack: (0xc0c93e20 to 0xc0c94000)
      3e20: c021f058 e9a17178 e9a171bc e99dfd6c 00000001 00000001 e995de10 00000002
      3e40: 00000000 c021b574 00000000 c04bc4a4 00000000 e9b49ac0 c0ce6e6c e99dfda4
      3e60: 00000088 e9810780 c0d8291c c072ea58 00000000 c072d3fc 00000000 c072f534
      3e80: 00000000 e9b49ac0 00000100 c0c9a444 00000088 c072f6b4 c072f5d4 e9d40080
      3ea0: e98107dc 00000000 00000000 c0280a60 00000000 7d55bf61 e9810780 e98107dc
      3ec0: 00000000 f0002000 c0d460e8 c0d460e8 c0c92000 c0280b60 e9810780 c0ce7190
      3ee0: 00000000 c028369c c02835f4 00000088 00000088 c0280278 c0c8ec70 c020f080
      3f00: f000200c c0c9a958 c0c93f28 c02088e4 c04bd630 c04bd5bc 200f0013 ffffffff
      3f20: c0c93f5c c0212800 00000001 a987c000 c0c93f3c c04bd574 00000000 0000015b
      3f40: ea7a0e40 00000000 c0d460e8 c0d460e8 c0c92000 c08ea538 29b12000 c0c93f70
      3f60: c04bd630 c04bd5bc 200f0013 ffffffff c04bd574 c071bd24 7d50c9b4 c0719a44
      3f80: 7d50c9b4 0000015b c0c9a498 c0c92028 c0c9a498 c0c9a4fc ea7a0e40 c0c8ee38
      3fa0: c0d460e8 c0276198 00000000 c0d8291a 00000000 c0c9a400 00000000 c0be0bc4
      3fc0: ffffffff ffffffff c0be05f8 00000000 00000000 c0c533d8 c0d82ed4 c0c9a47c
      3fe0: c0c533d4 c0c9e870 8020406a 511f06f0 00000000 80208074 00000000 00000000
      [<c021efc0>] (v7_dma_inv_range) from [<c021af18>] (__dma_page_dev_to_cpu+0x80/0x100)
      [<c021af18>] (__dma_page_dev_to_cpu) from [<c021b574>] (arm_dma_unmap_sg+0x5c/0x84)
      [<c021b574>] (arm_dma_unmap_sg) from [<c072ea58>] (mmci_dma_unmap.isra.16+0x60/0x74)
      [<c072ea58>] (mmci_dma_unmap.isra.16) from [<c072f534>] (mmci_data_irq+0x1fc/0x29c)
      [<c072f534>] (mmci_data_irq) from [<c072f6b4>] (mmci_irq+0xe0/0x114)
      [<c072f6b4>] (mmci_irq) from [<c0280a60>] (handle_irq_event_percpu+0x78/0x134)
      [<c0280a60>] (handle_irq_event_percpu) from [<c0280b60>] (handle_irq_event+0x44/0x64)
      [<c0280b60>] (handle_irq_event) from [<c028369c>] (handle_fasteoi_irq+0xa8/0x1a8)
      [<c028369c>] (handle_fasteoi_irq) from [<c0280278>] (generic_handle_irq+0x2c/0x3c)
      [<c0280278>] (generic_handle_irq) from [<c020f080>] (handle_IRQ+0x40/0x90)
      [<c020f080>] (handle_IRQ) from [<c02088e4>] (gic_handle_irq+0x38/0x68)
      [<c02088e4>] (gic_handle_irq) from [<c0212800>] (__irq_svc+0x40/0x54)
      Exception stack(0xc0c93f28 to 0xc0c93f70)
      3f20:                   00000001 a987c000 c0c93f3c c04bd574 00000000 0000015b
      3f40: ea7a0e40 00000000 c0d460e8 c0d460e8 c0c92000 c08ea538 29b12000 c0c93f70
      3f60: c04bd630 c04bd5bc 200f0013 ffffffff
      [<c0212800>] (__irq_svc) from [<c04bd5bc>] (msm_cpu_pm_enter_sleep+0x48/0x4c)
      [<c04bd5bc>] (msm_cpu_pm_enter_sleep) from [<c071bd24>] (qcom_lpm_enter_spc+0x20/0x2c)
      [<c071bd24>] (qcom_lpm_enter_spc) from [<c0719a44>] (cpuidle_enter_state+0x44/0xf0)
      [<c0719a44>] (cpuidle_enter_state) from [<c0276198>] (cpu_startup_entry+0x1f4/0x238)
      [<c0276198>] (cpu_startup_entry) from [<c0be0bc4>] (start_kernel+0x384/0x390)
      Code: 1e070f3e e1110003 e1c11003 1e071f3e (ee070f36)
      ---[ end trace cf6cb3f6432c9834 ]---
      Kernel panic - not syncing: Fatal exception in interrupt
      Reported-by: NNicolas Dechesne <nicolas.dechesne@linaro.org>
      Signed-off-by: NSrinivas Kandagatla <srinivas.kandagatla@linaro.org>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      64b12a68
    • A
      mmc: core: Add debug message for SET_BLOCK_COUNT result · fc75b708
      Andrew Gabbasov 提交于
      The debug messages with commands execution results, that are printed
      after processing the request, do not include results of sbc (set block count)
      part of request. Add the debug message for that part too.
      Signed-off-by: NAndrew Gabbasov <andrew_gabbasov@mentor.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      fc75b708
    • A
      mmc: core: Initialize SET_BLOCK_COUNT request fields · cce411e6
      Andrew Gabbasov 提交于
      Some request fields are initialized just before request processing
      for sanity purposes. This is done for command, data, and stop parts
      of the request, but not for sbc (set block count) part. Add such
      initialization for that part too.
      Signed-off-by: NAndrew Gabbasov <andrew_gabbasov@mentor.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      cce411e6
  3. 29 9月, 2014 1 次提交
  4. 24 9月, 2014 2 次提交
  5. 09 9月, 2014 3 次提交
    • C
      mmc: core: resolve divded by zero panic · cc8aa7de
      Chuanxiao Dong 提交于
      With one special SD card, below divide by zero error observed:
      ...
      [    2.144300] divide error: 0000 [#1] PREEMPT SMP
      [    2.148860] Modules linked in:
      [    2.151898]
      [    2.152685] Set up 4031 stolen pages starting at 0x0001f000, GTT offset 0K
      [    2.157330] Set up 0 CI stolen pages starting at 0x00000000, GTT offset 131072K
      [    2.167581] Pid: 5, comm: kworker/u:0 Not tainted 3.0.8-138216-g974a2aba #1
      [    2.169506] [drm] PSB GTT mem manager ready, tt_start 4031, tt_size 28737 pages
      [    2.169906] [drm] SGX core id = 0x00000000
      [    2.169920] [drm] SGX core rev major = 0x00, minor = 0x00
      [    2.169934] [drm] SGX core rev maintenance = 0x00, designer = 0x00
      [    2.197370]  Intel Corporation Medfield/iCDKB
      [    2.201716] EIP: 0060:[<c1697ca6>] EFLAGS: 00010246 CPU: 1
      [    2.207198] EIP is at mmc_init_erase+0x76/0x150
      [    2.211704] EAX: 00002000 EBX: dcd1b400 ECX: 00002000 EDX: 00000000
      [    2.217957] ESI: 00000000 EDI: dcd5c800 EBP: dd867e84 ESP: dd867e7c
      [    2.224214]  DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
      [    2.229605] Process kworker/u:0 (pid: 5, ti=dd866000 task=dd868000 task.ti=dd866000)
      [    2.237325] Stack:
      [    2.239322]  dcd1b400 00000000 dd867eb0 c16a06da c1ab7c44 dd995aa8 00000003 00000000
      [    2.247054]  00000000 00000000 dcd5c800 00000000 dcd1b400 dd867ef8 c16a1012 c1698b00
      [    2.254785]  00000029 00000001 c194eb80 dcd5c9ec dd867e00 c1239b00 00000000 00000000
      [    2.262519] Call Trace:
      [    2.264975]  [<c16a06da>] mmc_sd_setup_card+0x1da/0x4f0
      [    2.270183]  [<c16a1012>] mmc_sd_init_card+0x192/0xc40
      [    2.275304]  [<c1698b00>] ? __mmc_claim_host+0x160/0x160
      [    2.280610]  [<c1239b00>] ? __schedule_bug+0x50/0x80
      [    2.285556]  [<c16a1b89>] mmc_attach_sd+0xc9/0x230
      [    2.290333]  [<c169b6ef>] mmc_rescan+0x25f/0x2c0
      [    2.294943]  [<c1274223>] process_one_work+0x103/0x400
      [    2.300065]  [<c12670fd>] ? mod_timer+0x1ad/0x3c0
      [    2.304756]  [<c169b490>] ? mmc_suspend_host+0x1a0/0x1a0
      [    2.310056]  [<c127502d>] worker_thread+0x12d/0x4a0
      [    2.314921]  [<c18fcfbd>] ? preempt_schedule+0x2d/0x50
      [    2.320047]  [<c1274f00[    2.323976] ---[ end trace 5398ec2720494438 ]---
      ...
      
      So, seems this bad SD card does not set valid value in related SSR / CSD register fields.
      And then the driver will set card->erase_size to 0.
      Then it triggered this divided by zero error when calculate card->pref_erase.
      
      Submit this patch to fix the issue.
      Signed-off-by: NYunpeng Gao <yunpeng.gao@intel.com>
      Signed-off-by: NChuanxiao Dong <chuanxiao.dong@intel.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      cc8aa7de
    • J
      mmc: core: Use regulator_get_voltage() if OCR mask is empty. · 9ed7ca89
      Javier Martinez Canillas 提交于
      The operation conditions register (OCR) stores the voltage
      profile of the card, however the list of possible voltages
      is restricted by the voltage range supported by the supply
      used as VCC/VDD. So in mmc_vddrange_to_ocrmask() a OCR mask
      is obtained to filter the not supported voltages, from the
      value read in the host controller OCR register.
      
      For fixed regulators, regulator_list_voltage() returns the
      fixed output for the first selector but this doesn't happen
      for switch (FET) regulators that obtain their voltage from
      their parent supply. A call to regulator_get_voltage() is
      needed in this case so the regulator core can return the
      FET's parent supply voltage output.
      
      This change is consistent with the fact that for other
      fixed regulators (that are not FETs) the OCR mask is
      returned even when mmc_regulator_set_ocr() checks if the
      regulator is fixed before calling regulator_set_voltage().
      
      Without this patch, the following warning is reported when
      a FET is used as a vmmc-supply:
      
      dwmmc_exynos 12220000.mmc: Failed getting OCR mask: -22
      Signed-off-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      9ed7ca89
    • T
      mmc: core: Remove fixed voltage regulator logic · ca6429d4
      Tim Kryger 提交于
      There is no need for regulator consumers to include special logic for
      fixed voltage regulators as they support regulator_set_voltage() just
      like their non-fixed regulator counterparts.
      Signed-off-by: NTim Kryger <tim.kryger@gmail.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      ca6429d4
  6. 26 7月, 2014 1 次提交
  7. 13 5月, 2014 3 次提交
  8. 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
  9. 17 3月, 2014 1 次提交
  10. 23 2月, 2014 3 次提交
  11. 14 2月, 2014 4 次提交
  12. 14 1月, 2014 1 次提交
  13. 31 10月, 2013 8 次提交
  14. 26 9月, 2013 1 次提交
  15. 26 8月, 2013 1 次提交
  16. 31 7月, 2013 1 次提交
  17. 28 6月, 2013 1 次提交