1. 05 9月, 2012 12 次提交
    • 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 21 次提交
  4. 31 7月, 2012 3 次提交
    • A
      vfio: Add PCI device driver · 89e1f7d4
      Alex Williamson 提交于
      Add PCI device support for VFIO.  PCI devices expose regions
      for accessing config space, I/O port space, and MMIO areas
      of the device.  PCI config access is virtualized in the kernel,
      allowing us to ensure the integrity of the system, by preventing
      various accesses while reducing duplicate support across various
      userspace drivers.  I/O port supports read/write access while
      MMIO also supports mmap of sufficiently sized regions.  Support
      for INTx, MSI, and MSI-X interrupts are provided using eventfds to
      userspace.
      Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      89e1f7d4
    • A
      vfio: Type1 IOMMU implementation · 73fa0d10
      Alex Williamson 提交于
      This VFIO IOMMU backend is designed primarily for AMD-Vi and Intel
      VT-d hardware, but is potentially usable by anything supporting
      similar mapping functionality.  We arbitrarily call this a Type1
      backend for lack of a better name.  This backend has no IOVA
      or host memory mapping restrictions for the user and is optimized
      for relatively static mappings.  Mapped areas are pinned into system
      memory.
      Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      73fa0d10
    • A
      vfio: VFIO core · cba3345c
      Alex Williamson 提交于
      VFIO is a secure user level driver for use with both virtual machines
      and user level drivers.  VFIO makes use of IOMMU groups to ensure the
      isolation of devices in use, allowing unprivileged user access.  It's
      intended that VFIO will replace KVM device assignment and UIO drivers
      (in cases where the target platform includes a sufficiently capable
      IOMMU).
      
      New in this version of VFIO is support for IOMMU groups managed
      through the IOMMU core as well as a rework of the API, removing the
      group merge interface.  We now go back to a model more similar to
      original VFIO with UIOMMU support where the file descriptor obtained
      from /dev/vfio/vfio allows access to the IOMMU, but only after a
      group is added, avoiding the previous privilege issues with this type
      of model.  IOMMU support is also now fully modular as IOMMUs have
      vastly different interface requirements on different platforms.  VFIO
      users are able to query and initialize the IOMMU model of their
      choice.
      
      Please see the follow-on Documentation commit for further description
      and usage example.
      Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      cba3345c