1. 05 9月, 2012 18 次提交
    • S
      mmc: sdhci-dove: DT support for sdhci-dove · 4ee7ed0d
      Sebastian Hesselbarth 提交于
      This patch adds device tree support and binding documentation for
      sdhci-dove.
      Signed-off-by: NSebastian Hesselbarth <sebastian.hesselbarth@googlemail.com>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      4ee7ed0d
    • C
      mmc: sdhci-pxav2, sdhci-pxav3: use clk_prepare/unprepare APIs · 164378ef
      Chao Xie 提交于
      Prepare the clock before enabling it.
      Signed-off-by: NChao Xie <xiechao.mail@gmail.com>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      164378ef
    • L
    • P
      mmc: sdhci: vmmc regulator should be explicitly enabled/disabled · 77dcb3f4
      Philip Rakity 提交于
      The vmmc regulator should not rely on the platform code to enable it.
      Expliciitly enable and disable the regulator inside the driver.
      Signed-off-by: NPhilip Rakity <prakity@marvell.com>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      77dcb3f4
    • P
      mmc: sdhci: Add regulator support for vccq (voltage regualor) · 6231f3de
      Philip Rakity 提交于
      On some systems the host controller does not support vccq
      signaling.  This is supplied by a dedicated regulator (vqmmc).
      Add support for this regulator.
      Signed-off-by: NPhilip Rakity <prakity@marvell.com>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      6231f3de
    • J
      mmc: eSDHC: Add ADMA mode support · 137ccd46
      Jerry Huang 提交于
      The register of eSDHC Host Controller Capabilities is not compatible with
      standard SDHC register, and eSDHC cannot support End Attribute in NOP ADMA
      descriptor. With this patch eSDHC can works in ADMA mode and performance
      can be improved.
      Signed-off-by: NJerry Huang <Chang-Ming.Huang@freescale.com>
      Signed-off-by: NPan Jiafei <Jiafei.Pan@freescale.com>
      Signed-off-by: NJason Jin <Jason.jin@freescale.com>
      Acked-by: NAnton Vorontsov <cbouatmailru@gmail.com>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      137ccd46
    • D
      mmc: pxa-mci: add DT bindings · e6027b46
      Daniel Mack 提交于
      Signed-off-by: NDaniel Mack <zonque@gmail.com>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      e6027b46
    • P
      mmc: omap: fix broken PIO mode · 75b53aee
      Paul Walmsley 提交于
      After commit 26b88520 ("mmc:
      omap_hsmmc: remove private DMA API implementation"), the Nokia N800
      here stopped booting:
      
      [    2.086181] Waiting for root device /dev/mmcblk0p1...
      [    2.324066] Unhandled fault: imprecise external abort (0x406) at 0x00000000
      [    2.331451] Internal error: : 406 [#1] ARM
      [    2.335784] Modules linked in:
      [    2.339050] CPU: 0    Not tainted  (3.6.0-rc3 #60)
      [    2.344146] PC is at default_idle+0x28/0x30
      [    2.348602] LR is at trace_hardirqs_on_caller+0x15c/0x1b0
      
      ...
      
      This turned out to be due to memory corruption caused by long-broken
      PIO code in drivers/mmc/host/omap.c.  (Previously, this driver had
      been using DMA; but the above commit caused the MMC driver to fall
      back to PIO mode with an unmodified Kconfig.)
      
      The PIO code, added with the rest of the driver in commit
      730c9b7e ("[MMC] Add OMAP MMC host
      driver"), confused bytes with 16-bit words.  This bug caused memory
      located after the PIO transfer buffer to be corrupted with transfers
      larger than 32 bytes.  The driver also did not increment the buffer
      pointer after the transfer occurred.  This bug resulted in data
      corruption during any transfer larger than 64 bytes.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Reviewed-by: NFelipe Balbi <balbi@ti.com>
      Tested-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      75b53aee
    • I
      mmc: card: Skip secure erase on MoviNAND; causes unrecoverable corruption. · 3550ccdb
      Ian Chen 提交于
      For several MoviNAND eMMC parts, there are known issues with secure
      erase and secure trim.  For these specific MoviNAND devices, we skip
      these operations.
      
      Specifically, there is a bug in the eMMC firmware that causes
      unrecoverable corruption when the MMC is erased with MMC_CAP_ERASE
      enabled.
      
      References:
      
      http://forum.xda-developers.com/showthread.php?t=1644364
      https://plus.google.com/111398485184813224730/posts/21pTYfTsCkB#111398485184813224730/posts/21pTYfTsCkBSigned-off-by: NIan Chen <ian.cy.chen@samsung.com>
      Reviewed-by: NNamjae Jeon <linkinjeon@gmail.com>
      Acked-by: NJaehoon Chung <jh80.chung@samsung.com>
      Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
      Cc: stable <stable@vger.kernel.org> [3.0+]
      Signed-off-by: NChris Ball <cjb@laptop.org>
      3550ccdb
    • D
      mmc: dw_mmc: Disable low power mode if SDIO interrupts are used · 9623b5b9
      Doug Anderson 提交于
      The documentation for the dw_mmc part says that the low power
      mode should normally only be set for MMC and SD memory and should
      be turned off for SDIO cards that need interrupts detected.
      
      The best place I could find to do this is when the SDIO interrupt
      was first enabled.  I rely on the fact that dw_mci_setup_bus()
      will be called when it's time to reenable.
      Signed-off-by: NDoug Anderson <dianders@chromium.org>
      Acked-by: NSeungwon Jeon <tgih.jun@samsung.com>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      9623b5b9
    • S
      mmc: dw_mmc: fix error handling in PIO mode · e74f3a9c
      Seungwon Jeon 提交于
      Data transfer will be continued until all the bytes are transmitted,
      even if data crc error occurs during a multiple-block data transfer.
      This means RXDR/TXDR interrupts will occurs until data transfer is
      terminated. Early setting of host->sg to NULL prevents going into
      xxx_data_pio functions, hence permanent unhandled RXDR/TXDR interrupts
      occurs. And checking error interrupt status in the xxx_data_pio functions
      is no need because dw_mci_interrupt does do the same. This patch also
      removes it.
      Signed-off-by: NSeungwon Jeon <tgih.jun@samsung.com>
      Acked-by: NJaehoon Chung <jh80.chung@samsung.com>
      Acked-by: NWill Newton <will.newton@imgtec.com>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      e74f3a9c
    • S
      mmc: dw_mmc: correct mishandling error interrupt · 9b2026a1
      Seungwon Jeon 提交于
      Datasheet of SYNOPSYS mentions that DTO(Data Transfer Over) interrupt
      will be raised even if some error interrupts, however it is actually
      found that DTO does not occur. SYNOPSYS has confirmed this issue.
      Current implementation defers the call of tasklet_schedule until DTO
      when the error interrupts is happened. This patch fixes error handling.
      Signed-off-by: NSeungwon Jeon <tgih.jun@samsung.com>
      Acked-by: NJaehoon Chung <jh80.chung@samsung.com>
      Acked-by: NWill Newton <will.newton@imgtec.com>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      9b2026a1
    • S
      mmc: dw_mmc: amend using error interrupt status · 182c9081
      Seungwon Jeon 提交于
      RINTSTS status includes masked interrupts as well as unmasked.
      data_status and cmd_status are set by value of RINTSTS in interrupt handler
      and tasklet finally uses it to decide whether error is happened or not.
      In addition, MINTSTS status is used for setting data_status in PIO.
      Masked error interrupt will not be handled and that status can be considered
      non-error case.
      Signed-off-by: NSeungwon Jeon <tgih.jun@samsung.com>
      Reviewed By: Girish K S <girish.shivananjappa@linaro.org>
      Acked-by: NJaehoon Chung <jh80.chung@samsung.com>
      Acked-by: NWill Newton <will.newton@imgtec.com>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      182c9081
    • L
      mmc: atmel-mci: not busy flag has also to be used for read operations · 077d4073
      Ludovic Desroches 提交于
      Even if the datasheet says that the not busy flag has to be used only
      for write operations, it's false except for version lesser than v2xx.
      
      Not waiting on the not busy flag for read operations can cause the
      controller to hang-up during the initialization of some SD cards
      with DMA after the first CMD6 -- the next command is sent too early.
      Signed-off-by: NLudovic Desroches <ludovic.desroches@atmel.com>
      Cc: stable <stable@vger.kernel.org> [3.5, 3.6]
      Signed-off-by: NChris Ball <cjb@laptop.org>
      077d4073
    • S
      mmc: sdhci-esdhc: break out early if clock is 0 · 74f330bc
      Shawn Guo 提交于
      Since commit 30832ab5 ("mmc: sdhci: Always pass clock request value
      zero to set_clock host op") was merged, esdhc_set_clock starts hitting
      "if (clock == 0)" where ESDHC_SYSTEM_CONTROL has been operated.  This
      causes SDHCI card-detection function being broken.  Fix the regression
      by moving "if (clock == 0)" above ESDHC_SYSTEM_CONTROL operation.
      Signed-off-by: NShawn Guo <shawn.guo@linaro.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      74f330bc
    • L
      mmc: mxs-mmc: fix deadlock caused by recursion loop · fc108d24
      Lauri Hintsala 提交于
      Release the lock before mmc_signal_sdio_irq is called by
      mxs_mmc_enable_sdio_irq.
      
      Backtrace:
      [   65.470000] =============================================
      [   65.470000] [ INFO: possible recursive locking detected ]
      [   65.470000] 3.5.0-rc5 #2 Not tainted
      [   65.470000] ---------------------------------------------
      [   65.470000] ksdioirqd/mmc0/73 is trying to acquire lock:
      [   65.470000]  (&(&host->lock)->rlock#2){-.-...}, at: [<bf054120>] mxs_mmc_enable_sdio_irq+0x18/0xdc [mxs_mmc]
      [   65.470000]
      [   65.470000] but task is already holding lock:
      [   65.470000]  (&(&host->lock)->rlock#2){-.-...}, at: [<bf054120>] mxs_mmc_enable_sdio_irq+0x18/0xdc [mxs_mmc]
      [   65.470000]
      [   65.470000] other info that might help us debug this:
      [   65.470000]  Possible unsafe locking scenario:
      [   65.470000]
      [   65.470000]        CPU0
      [   65.470000]        ----
      [   65.470000]   lock(&(&host->lock)->rlock#2);
      [   65.470000]   lock(&(&host->lock)->rlock#2);
      [   65.470000]
      [   65.470000]  *** DEADLOCK ***
      [   65.470000]
      [   65.470000]  May be due to missing lock nesting notation
      [   65.470000]
      [   65.470000] 1 lock held by ksdioirqd/mmc0/73:
      [   65.470000]  #0:  (&(&host->lock)->rlock#2){-.-...}, at: [<bf054120>] mxs_mmc_enable_sdio_irq+0x18/0xdc [mxs_mmc]
      [   65.470000]
      [   65.470000] stack backtrace:
      [   65.470000] [<c0014990>] (unwind_backtrace+0x0/0xf4) from [<c005ccb8>] (__lock_acquire+0x14f8/0x1b98)
      [   65.470000] [<c005ccb8>] (__lock_acquire+0x14f8/0x1b98) from [<c005d3f8>] (lock_acquire+0xa0/0x108)
      [   65.470000] [<c005d3f8>] (lock_acquire+0xa0/0x108) from [<c02f671c>] (_raw_spin_lock_irqsave+0x48/0x5c)
      [   65.470000] [<c02f671c>] (_raw_spin_lock_irqsave+0x48/0x5c) from [<bf054120>] (mxs_mmc_enable_sdio_irq+0x18/0xdc [mxs_mmc])
      [   65.470000] [<bf054120>] (mxs_mmc_enable_sdio_irq+0x18/0xdc [mxs_mmc]) from [<bf0541d0>] (mxs_mmc_enable_sdio_irq+0xc8/0xdc [mxs_mmc])
      [   65.470000] [<bf0541d0>] (mxs_mmc_enable_sdio_irq+0xc8/0xdc [mxs_mmc]) from [<c0219b38>] (sdio_irq_thread+0x1bc/0x274)
      [   65.470000] [<c0219b38>] (sdio_irq_thread+0x1bc/0x274) from [<c003c324>] (kthread+0x8c/0x98)
      [   65.470000] [<c003c324>] (kthread+0x8c/0x98) from [<c00101ac>] (kernel_thread_exit+0x0/0x8)
      [   65.470000] BUG: spinlock lockup suspected on CPU#0, ksdioirqd/mmc0/73
      [   65.470000]  lock: 0xc3358724, .magic: dead4ead, .owner: ksdioirqd/mmc0/73, .owner_cpu: 0
      [   65.470000] [<c0014990>] (unwind_backtrace+0x0/0xf4) from [<c01b46b0>] (do_raw_spin_lock+0x100/0x144)
      [   65.470000] [<c01b46b0>] (do_raw_spin_lock+0x100/0x144) from [<c02f6724>] (_raw_spin_lock_irqsave+0x50/0x5c)
      [   65.470000] [<c02f6724>] (_raw_spin_lock_irqsave+0x50/0x5c) from [<bf054120>] (mxs_mmc_enable_sdio_irq+0x18/0xdc [mxs_mmc])
      [   65.470000] [<bf054120>] (mxs_mmc_enable_sdio_irq+0x18/0xdc [mxs_mmc]) from [<bf0541d0>] (mxs_mmc_enable_sdio_irq+0xc8/0xdc [mxs_mmc])
      [   65.470000] [<bf0541d0>] (mxs_mmc_enable_sdio_irq+0xc8/0xdc [mxs_mmc]) from [<c0219b38>] (sdio_irq_thread+0x1bc/0x274)
      [   65.470000] [<c0219b38>] (sdio_irq_thread+0x1bc/0x274) from [<c003c324>] (kthread+0x8c/0x98)
      [   65.470000] [<c003c324>] (kthread+0x8c/0x98) from [<c00101ac>] (kernel_thread_exit+0x0/0x8)
      Reported-by: NAttila Kinali <attila@kinali.ch>
      Signed-off-by: NLauri Hintsala <lauri.hintsala@bluegiga.com>
      Acked-by: NShawn Guo <shawn.guo@linaro.org>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      fc108d24
    • L
      mmc: mxs-mmc: fix deadlock in SDIO IRQ case · 1af36b2a
      Lauri Hintsala 提交于
      Release the lock before mmc_signal_sdio_irq is called by mxs_mmc_irq_handler.
      
      Backtrace:
      [   79.660000] =============================================
      [   79.660000] [ INFO: possible recursive locking detected ]
      [   79.660000] 3.4.0-00009-g3e96082-dirty #11 Not tainted
      [   79.660000] ---------------------------------------------
      [   79.660000] swapper/0 is trying to acquire lock:
      [   79.660000]  (&(&host->lock)->rlock#2){-.....}, at: [<c026ea3c>] mxs_mmc_enable_sdio_irq+0x18/0xd4
      [   79.660000]
      [   79.660000] but task is already holding lock:
      [   79.660000]  (&(&host->lock)->rlock#2){-.....}, at: [<c026f744>] mxs_mmc_irq_handler+0x1c/0xe8
      [   79.660000]
      [   79.660000] other info that might help us debug this:
      [   79.660000]  Possible unsafe locking scenario:
      [   79.660000]
      [   79.660000]        CPU0
      [   79.660000]        ----
      [   79.660000]   lock(&(&host->lock)->rlock#2);
      [   79.660000]   lock(&(&host->lock)->rlock#2);
      [   79.660000]
      [   79.660000]  *** DEADLOCK ***
      [   79.660000]
      [   79.660000]  May be due to missing lock nesting notation
      [   79.660000]
      [   79.660000] 1 lock held by swapper/0:
      [   79.660000]  #0:  (&(&host->lock)->rlock#2){-.....}, at: [<c026f744>] mxs_mmc_irq_handler+0x1c/0xe8
      [   79.660000]
      [   79.660000] stack backtrace:
      [   79.660000] [<c0014bd0>] (unwind_backtrace+0x0/0xf4) from [<c005f9c0>] (__lock_acquire+0x1948/0x1d48)
      [   79.660000] [<c005f9c0>] (__lock_acquire+0x1948/0x1d48) from [<c005fea0>] (lock_acquire+0xe0/0xf8)
      [   79.660000] [<c005fea0>] (lock_acquire+0xe0/0xf8) from [<c03a8460>] (_raw_spin_lock_irqsave+0x44/0x58)
      [   79.660000] [<c03a8460>] (_raw_spin_lock_irqsave+0x44/0x58) from [<c026ea3c>] (mxs_mmc_enable_sdio_irq+0x18/0xd4)
      [   79.660000] [<c026ea3c>] (mxs_mmc_enable_sdio_irq+0x18/0xd4) from [<c026f7fc>] (mxs_mmc_irq_handler+0xd4/0xe8)
      [   79.660000] [<c026f7fc>] (mxs_mmc_irq_handler+0xd4/0xe8) from [<c006bdd8>] (handle_irq_event_percpu+0x70/0x254)
      [   79.660000] [<c006bdd8>] (handle_irq_event_percpu+0x70/0x254) from [<c006bff8>] (handle_irq_event+0x3c/0x5c)
      [   79.660000] [<c006bff8>] (handle_irq_event+0x3c/0x5c) from [<c006e6d0>] (handle_level_irq+0x90/0x110)
      [   79.660000] [<c006e6d0>] (handle_level_irq+0x90/0x110) from [<c006b930>] (generic_handle_irq+0x38/0x50)
      [   79.660000] [<c006b930>] (generic_handle_irq+0x38/0x50) from [<c00102fc>] (handle_IRQ+0x30/0x84)
      [   79.660000] [<c00102fc>] (handle_IRQ+0x30/0x84) from [<c000f058>] (__irq_svc+0x38/0x60)
      [   79.660000] [<c000f058>] (__irq_svc+0x38/0x60) from [<c0010520>] (default_idle+0x2c/0x40)
      [   79.660000] [<c0010520>] (default_idle+0x2c/0x40) from [<c0010a90>] (cpu_idle+0x64/0xcc)
      [   79.660000] [<c0010a90>] (cpu_idle+0x64/0xcc) from [<c04ff858>] (start_kernel+0x244/0x2c8)
      [   79.660000] BUG: spinlock lockup on CPU#0, swapper/0
      [   79.660000]  lock: c398cb2c, .magic: dead4ead, .owner: swapper/0, .owner_cpu: 0
      [   79.660000] [<c0014bd0>] (unwind_backtrace+0x0/0xf4) from [<c01ddb1c>] (do_raw_spin_lock+0xf0/0x144)
      [   79.660000] [<c01ddb1c>] (do_raw_spin_lock+0xf0/0x144) from [<c03a8468>] (_raw_spin_lock_irqsave+0x4c/0x58)
      [   79.660000] [<c03a8468>] (_raw_spin_lock_irqsave+0x4c/0x58) from [<c026ea3c>] (mxs_mmc_enable_sdio_irq+0x18/0xd4)
      [   79.660000] [<c026ea3c>] (mxs_mmc_enable_sdio_irq+0x18/0xd4) from [<c026f7fc>] (mxs_mmc_irq_handler+0xd4/0xe8)
      [   79.660000] [<c026f7fc>] (mxs_mmc_irq_handler+0xd4/0xe8) from [<c006bdd8>] (handle_irq_event_percpu+0x70/0x254)
      [   79.660000] [<c006bdd8>] (handle_irq_event_percpu+0x70/0x254) from [<c006bff8>] (handle_irq_event+0x3c/0x5c)
      [   79.660000] [<c006bff8>] (handle_irq_event+0x3c/0x5c) from [<c006e6d0>] (handle_level_irq+0x90/0x110)
      [   79.660000] [<c006e6d0>] (handle_level_irq+0x90/0x110) from [<c006b930>] (generic_handle_irq+0x38/0x50)
      [   79.660000] [<c006b930>] (generic_handle_irq+0x38/0x50) from [<c00102fc>] (handle_IRQ+0x30/0x84)
      [   79.660000] [<c00102fc>] (handle_IRQ+0x30/0x84) from [<c000f058>] (__irq_svc+0x38/0x60)
      [   79.660000] [<c000f058>] (__irq_svc+0x38/0x60) from [<c0010520>] (default_idle+0x2c/0x40)
      [   79.660000] [<c0010520>] (default_idle+0x2c/0x40) from [<c0010a90>] (cpu_idle+0x64/0xcc)
      [   79.660000] [<c0010a90>] (cpu_idle+0x64/0xcc) from [<c04ff858>] (start_kernel+0x244/0x2c8)
      Signed-off-by: NLauri Hintsala <lauri.hintsala@bluegiga.com>
      Acked-by: NShawn Guo <shawn.guo@linaro.org>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      1af36b2a
    • S
      mmc: bfin_sdh: fix dma_desc_array build error · 660d9a9c
      Sonic Zhang 提交于
      Descriptor array structure has been moved into blackfin dma.h head file.
      This patch fix below error:
      
      drivers/mmc/host/bfin_sdh.c:52:8: error: redefinition of 'struct
      dma_desc_array'
      make[4]: *** [drivers/mmc/host/bfin_sdh.o] Error 1
      Signed-off-by: NSonic Zhang <sonic.zhang@analog.com>
      Signed-off-by: NBob Liu <lliubbo@gmail.com>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      660d9a9c
  2. 02 8月, 2012 4 次提交
  3. 01 8月, 2012 18 次提交