1. 14 Feb, 2011 3 commits
    • Dan Williams's avatar
      Merge branch 'dma40' into dmaengine · 80cc07af
      Dan Williams authored
      80cc07af
    • Dan Williams's avatar
      Merge branch 'imx' into dmaengine-fixes · e19d1d49
      Dan Williams authored
      e19d1d49
    • Anatolij Gustschin's avatar
      dma: ipu_idmac: do not lose valid received data in the irq handler · a646bd7f
      Anatolij Gustschin authored
      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: default avatarAnatolij Gustschin <agust@denx.de>
      Reviewed-by: default avatarGuennadi Liakhovetski <g.liakhovetski@gmx.de>
      Tested-by: default avatarGuennadi Liakhovetski <g.liakhovetski@gmx.de>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      a646bd7f
  2. 31 Jan, 2011 37 commits