1. 07 6月, 2012 2 次提交
  2. 15 5月, 2012 3 次提交
  3. 12 5月, 2012 4 次提交
  4. 11 5月, 2012 8 次提交
  5. 09 5月, 2012 1 次提交
  6. 25 4月, 2012 5 次提交
  7. 23 4月, 2012 4 次提交
  8. 20 4月, 2012 4 次提交
  9. 17 4月, 2012 1 次提交
  10. 06 4月, 2012 4 次提交
  11. 30 3月, 2012 1 次提交
    • R
      ARM: sa11x0: fix build errors from DMA engine API updates · d9d54540
      Russell King 提交于
      The recent merge of the sa11x0 code into mainline had silent conflicts
      with further development of the DMA engine API, leading to build errors
      and warnings:
      
      drivers/net/irda/sa1100_ir.c: In function 'sa1100_irda_dma_start':
      drivers/net/irda/sa1100_ir.c:151: error: too few arguments to function 'chan->device->device_prep_slave_sg'
      drivers/dma/sa11x0-dma.c: In function 'sa11x0_dma_probe':
      drivers/dma/sa11x0-dma.c:950: warning: assignment from incompatible pointer type
      
      Fix these.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      d9d54540
  12. 28 3月, 2012 2 次提交
    • D
      iop-adma: Corrected array overflow in RAID6 Xscale(R) test. · 3d9ea9e3
      Don Morris 提交于
      Bug: cppcheck reported overflow in array assignment (for loop walks
      0 to IOP_ADMA_NUM_SRC_TEST+2, array size is IOP_ADMA_NUM_SRC_TEST).
      
      Reported as: https://bugzilla.kernel.org/show_bug.cgi?id=42677
      
      Test code pq_src array was grown by two elements to correspond with actual
      usage (IOP_ADMA_NUM_SRC_TEST+2), stack consumption was kept constant by
      modifying the pq_dest two element array which is only used when pq_src
      is referenced up to IOP_ADMA_NUM_SRC_TEST elements into the address
      of the new last two elements of the pq_src array. This is presumed to
      be the original intent but would be reliant on compilers always having
      pq_dest contiguous with the final element of pq_src.
      
      Note: This is a re-send of a request for review from two weeks ago.
      Looking for review (or shootdown), adding LKML to list for a wider
      audience. Thanks.
      
      Updated per review comments of Sergei Shtylyov <sshtylyov@mvista.com>
      Signed-off-by: NDon Morris <don.morris@hp.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      3d9ea9e3
    • V
      dmaengine: imx: fix the build failure on x86_64 · 5b2e02e4
      Vinod Koul 提交于
      commit 6bd08127 "dmaengine: imx-dma: merge old dma-v1.c with
      imx-dma.c" removed the dependency in config for the imx dma driver,
      whereas it should depend on ARCH_MXS
      Signed-off-by: NVinod Koul <vinod.koul@linux.intel.com>
      5b2e02e4
  13. 27 3月, 2012 1 次提交
    • H
      mxs-dma : rewrite the last parameter of mxs_dma_prep_slave_sg() · 921de864
      Huang Shijie 提交于
      [1] Background :
          The GPMI does ECC read page operation with a DMA chain consist of three DMA
          Command Structures. The middle one of the chain is used to enable the BCH,
          and read out the NAND page.
      
          The WAIT4END(wait for command end) is a comunication signal between
          the GPMI and MXS-DMA.
      
      [2] The current DMA code sets the WAIT4END bit at the last one, such as:
      
          +-----+               +-----+                      +-----+
          | cmd | ------------> | cmd | ------------------>  | cmd |
          +-----+               +-----+                      +-----+
                                                                ^
                                                                |
                                                                |
                                                           set WAIT4END here
      
          This chain works fine in the mx23/mx28.
      
      [3] But in the new GPMI version (used in MX50/MX60), the WAIT4END bit should
          be set not only at the last DMA Command Structure,
          but also at the middle one, such as:
      
          +-----+               +-----+                      +-----+
          | cmd | ------------> | cmd | ------------------>  | cmd |
          +-----+               +-----+                      +-----+
                                   ^                            ^
                                   |                            |
                                   |                            |
                              set WAIT4END here too        set WAIT4END here
      
          If we do not set WAIT4END, the BCH maybe stalls in "ECC reading page" state.
          In the next ECC write page operation, a DMA-timeout occurs.
          This has been catched in the MX6Q board.
      
      [4] In order to fix the bug, rewrite the last parameter of mxs_dma_prep_slave_sg(),
          and use the dma_ctrl_flags:
          ---------------------------------------------------------
            DMA_PREP_INTERRUPT : append a new DMA Command Structrue.
            DMA_CTRL_ACK       : set the WAIT4END bit for this DMA Command Structure.
          ---------------------------------------------------------
      
      [5] changes to the relative drivers:
          <1> For mxs-mmc driver, just use the new flags, do not change any logic.
          <2> For gpmi-nand driver, and use the new flags to set the DMA
              chain, especially for ecc read page.
      Acked-by: NShawn Guo <shawn.guo@linaro.org>
      Signed-off-by: NHuang Shijie <b32955@freescale.com>
      Acked-by: NVinod Koul <vinod.koul@linux.intel.com>
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      921de864