1. 23 3月, 2011 2 次提交
  2. 12 3月, 2011 11 次提交
  3. 07 3月, 2011 15 次提交
  4. 02 3月, 2011 1 次提交
    • S
      dmaengine: mxs-dma: add dma support for i.MX23/28 · a580b8c5
      Shawn Guo 提交于
      This patch adds dma support for Freescale MXS-based SoC i.MX23/28,
      including apbh-dma and apbx-dma.
      
      * apbh-dma and apbx-dma are supported in the driver as two mxs-dma
        instances.
      
      * apbh-dma is different between mx23 and mx28, hardware version
        register is used to differentiate.
      
      * mxs-dma supports pio function besides data transfer.  The driver
        uses dma_data_direction DMA_NONE to identify the pio mode, and
        steals sgl and sg_len to get pio words and numbers from clients.
      
      * mxs dmaengine has some very specific features, like sense function
        and the special NAND support (nand_lock, nand_wait4ready).  These
        are too specific to implemented in generic dmaengine driver.
      
      * The driver refers to imx-sdma and only a single descriptor is
        statically assigned to each channel.
      Signed-off-by: NShawn Guo <shawn.guo@freescale.com>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      a580b8c5
  5. 26 2月, 2011 2 次提交
    • T
      pch_dma: set the number of array correctly · 26d890f0
      Tomoya MORINAGA 提交于
      set the number of array correctly.
      Signed-off-by: NTomoya MORINAGA <tomoya-linux@dsn.okisemi.com>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      26d890f0
    • T
      pch_dma: fix kernel error issue · c5a9f9d0
      Tomoya MORINAGA 提交于
      fix the following kernel error
      
      ------------[ cut here ]------------
      WARNING: at kernel/softirq.c:159 _local_bh_enable_ip.clone.5+0x35/0x71()
      Hardware name: To be filled by O.E.M.
      Modules linked in: pch_uart pch_dma fuse mga drm cpufreq_ondemand acpi_cpufreq mperf ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables ipv6 uinput snd_hda_codec_realtek snd_hda_intel snd_hda_codec matroxfb_base snd_hwdep 8250_pnp snd_seq snd_seq_device matroxfb_DAC1064 snd_pcm joydev 8250 matroxfb_accel snd_timer matroxfb_Ti3026 ppdev pegasus parport_pc snd parport matroxfb_g450 g450_pll serial_core video output matroxfb_misc soundcore snd_page_alloc serio_raw pcspkr ext4 jbd2 crc16 sdhci_pci sdhci mmc_core floppy [last unloaded: scsi_wait_scan]
      Pid: 0, comm: swapper Not tainted 2.6.37.upstream_check+ #8
      Call Trace:
       [<c0433add>] warn_slowpath_common+0x65/0x7a
       [<c043825b>] ? _local_bh_enable_ip.clone.5+0x35/0x71
       [<c0433b01>] warn_slowpath_null+0xf/0x13
       [<c043825b>] _local_bh_enable_ip.clone.5+0x35/0x71
       [<c043829f>] local_bh_enable_ip+0x8/0xa
       [<c06ec471>] _raw_spin_unlock_bh+0x10/0x12
       [<f82b57dd>] pd_prep_slave_sg+0xba/0x200 [pch_dma]
       [<f82f7b7a>] pch_uart_interrupt+0x44d/0x6aa [pch_uart]
       [<c046fa97>] handle_IRQ_event+0x1d/0x9e
       [<c047146f>] handle_fasteoi_irq+0x90/0xc7
       [<c04713df>] ? handle_fasteoi_irq+0x0/0xc7
       <IRQ>  [<c04045af>] ? do_IRQ+0x3e/0x89
       [<c04035a9>] ? common_interrupt+0x29/0x30
       [<c04400d8>] ? sys_getpriority+0x12d/0x1a2
       [<c058bb2b>] ? arch_local_irq_enable+0x5/0xb
       [<c058c740>] ? acpi_idle_enter_bm+0x22a/0x261
       [<c0648b11>] ? cpuidle_idle_call+0x70/0xa1
       [<c0401f44>] ? cpu_idle+0x49/0x6a
       [<c06d9fc4>] ? rest_init+0x58/0x5a
       [<c089e762>] ? start_kernel+0x2d0/0x2d5
       [<c089e0ce>] ? i386_start_kernel+0xce/0xd5
      Signed-off-by: NTomoya MORINAGA <tomoya-linux@dsn.okisemi.com>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      c5a9f9d0
  6. 14 2月, 2011 5 次提交
    • D
      Merge branch 'dw_dmac' into dmaengine · 0670e715
      Dan Williams 提交于
      0670e715
    • D
      Merge branch 'dma40' into dmaengine · 80cc07af
      Dan Williams 提交于
      80cc07af
    • D
      dmaengine: add slave-dma maintainer · 4abed0af
      Dan Williams 提交于
      Slave-dma has become the predominant usage model for dmaengine and needs
      special attention.  Memory-to-memory dma usage cases will continue to be
      maintained by Dan.
      
      Cc: Alan Cox <alan@linux.intel.com>
      Acked-by: NVinod Koul <vinod.koul@intel.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      4abed0af
    • D
      Merge branch 'imx' into dmaengine-fixes · e19d1d49
      Dan Williams 提交于
      e19d1d49
    • A
      dma: ipu_idmac: do not lose valid received data in the irq handler · a646bd7f
      Anatolij Gustschin 提交于
      Currently when two or more buffers are queued by the camera driver
      and so the double buffering is enabled in the idmac, we lose one
      frame comming from CSI since the reporting of arrival of the first
      frame is deferred by the DMAIC_7_EOF interrupt handler and reporting
      of the arrival of the last frame is not done at all. So when requesting
      N frames from the image sensor we actually receive N - 1 frames in
      user space.
      
      The reason for this behaviour is that the DMAIC_7_EOF interrupt
      handler misleadingly assumes that the CUR_BUF flag is pointing to the
      buffer used by the IDMAC. Actually it is not the case since the
      CUR_BUF flag will be flipped by the FSU when the FSU is sending the
      <TASK>_NEW_FRM_RDY signal when new frame data is delivered by the CSI.
      When sending this singal, FSU updates the DMA_CUR_BUF and the
      DMA_BUFx_RDY flags: the DMA_CUR_BUF is flipped, the DMA_BUFx_RDY
      is cleared, indicating that the frame data is beeing written by
      the IDMAC to the pointed buffer. DMA_BUFx_RDY is supposed to be
      set to the ready state again by the MCU, when it has handled the
      received data. DMAIC_7_CUR_BUF flag won't be flipped here by the
      IPU, so waiting for this event in the EOF interrupt handler is wrong.
      Actually there is no spurious interrupt as described in the comments,
      this is the valid DMAIC_7_EOF interrupt indicating reception of the
      frame from CSI.
      
      The patch removes code that waits for flipping of the DMAIC_7_CUR_BUF
      flag in the DMAIC_7_EOF interrupt handler. As the comment in the
      current code denotes, this waiting doesn't help anyway. As a result
      of this removal the reporting of the first arrived frame is not
      deferred to the time of arrival of the next frame and the drivers
      software flag 'ichan->active_buffer' is in sync with DMAIC_7_CUR_BUF
      flag, so the reception of all requested frames works.
      
      This has been verified on the hardware which is triggering the
      image sensor by the programmable state machine, allowing to
      obtain exact number of frames. On this hardware we do not tolerate
      losing frames.
      
      This patch also removes resetting the DMA_BUFx_RDY flags of
      all channels in ipu_disable_channel() since transfers on other
      DMA channels might be triggered by other running tasks and the
      buffers should always be ready for data sending or reception.
      Signed-off-by: NAnatolij Gustschin <agust@denx.de>
      Reviewed-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
      Tested-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      a646bd7f
  7. 31 1月, 2011 4 次提交