1. 08 7月, 2016 2 次提交
  2. 21 6月, 2016 2 次提交
    • K
      dmaengine: vdma: Add 64 bit addressing support for the axi cdma · 9791e71a
      Kedareswara rao Appana 提交于
      The AXI CDMA is a soft ip, which can be programmed to support
      32 bit addressing or greater than 32 bit addressing.
      
      When the AXI CDMA ip is configured for 32 bit address space
      in simple dma mode the source/destination buffer address is
      specified by a single register(18h for Source buffer address and
      20h for Destination buffer address). When configured in SG mode
      the current descriptor and tail descriptor are specified by a
      Single register(08h for curdesc 10h for tail desc).
      
      When the  AXI CDMA core is configured for an address space greater
      than 32 then each buffer address or descriptor address is specified by
      a combination of two registers.
      
      The first register specifies the LSB 32 bits of address,
      while the next register specifies the MSB 32 bits of address.
      
      For example, 08h will specify the LSB 32 bits while 0Ch will
      specify the MSB 32 bits of the first start address.
      So we need to program two registers at a time.
      
      This patch adds the 64 bit addressing support to the axicdma
      IP in the driver.
      Signed-off-by: NKedareswara rao Appana <appanad@xilinx.com>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      9791e71a
    • K
      dmaengine: vdma: Add 64 bit addressing support for the axi dma · f0cba685
      Kedareswara rao Appana 提交于
      The AXI DMA is a soft ip, which can be programmed to support
      32 bit addressing or greater than 32 bit addressing.
      
      When the AXI DMA ip is configured for 32 bit address space
      in simple dma mode the buffer address is specified by a single register
      (18h for MM2S channel and 48h for S2MM channel). When configured in SG mode
      The current descriptor and tail descriptor are specified by a single
      Register(08h for curdesc 10h for tail desc for MM2S channel and 38h for
      Curdesc and 40h for tail desc for S2MM).
      
      When the  AXI DMA core is configured for an address space greater
      than 32 then each buffer address or descriptor address is specified by
      a combination of two registers.
      
      The first register specifies the LSB 32 bits of address,
      while the next register specifies the MSB 32 bits of address.
      
      For example, 48h will specify the LSB 32 bits while 4Ch will
      specify the MSB 32 bits of the first start address.
      So we need to program two registers at a time.
      
      This patch adds the 64 bit addressing support for the axidma
      IP in the driver.
      Signed-off-by: NKedareswara rao Appana <appanad@xilinx.com>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      f0cba685
  3. 14 6月, 2016 1 次提交
    • A
      dmaengine: xilinx-vdma: add some sanity checks · f67c3bda
      Arnd Bergmann 提交于
      The newly added xilinx_dma_prep_dma_cyclic function sometimes causes
      a gcc warning about the use of the segment function in case
      we never run into the inner loop of the function:
      
      dma/xilinx/xilinx_vdma.c: In function 'xilinx_dma_prep_dma_cyclic':
      dma/xilinx/xilinx_vdma.c:1808:23: error: 'segment' may be used uninitialized in this function [-Werror=maybe-uninitialized]
         segment->hw.control |= XILINX_DMA_BD_SOP;
      
      This can only happen if the period len is zero (which would cause other
      problems earlier), or if the buffer is shorter than a period. Neither
      of them should ever happen, but by adding an explicit check for these two
      cases, we can abort in a more controlled way, and the compiler is
      able to see that we never use uninitialized data.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      f67c3bda
  4. 13 6月, 2016 1 次提交
  5. 07 6月, 2016 2 次提交
  6. 28 5月, 2016 1 次提交
    • A
      remove lots of IS_ERR_VALUE abuses · 287980e4
      Arnd Bergmann 提交于
      Most users of IS_ERR_VALUE() in the kernel are wrong, as they
      pass an 'int' into a function that takes an 'unsigned long'
      argument. This happens to work because the type is sign-extended
      on 64-bit architectures before it gets converted into an
      unsigned type.
      
      However, anything that passes an 'unsigned short' or 'unsigned int'
      argument into IS_ERR_VALUE() is guaranteed to be broken, as are
      8-bit integers and types that are wider than 'unsigned long'.
      
      Andrzej Hajda has already fixed a lot of the worst abusers that
      were causing actual bugs, but it would be nice to prevent any
      users that are not passing 'unsigned long' arguments.
      
      This patch changes all users of IS_ERR_VALUE() that I could find
      on 32-bit ARM randconfig builds and x86 allmodconfig. For the
      moment, this doesn't change the definition of IS_ERR_VALUE()
      because there are probably still architecture specific users
      elsewhere.
      
      Almost all the warnings I got are for files that are better off
      using 'if (err)' or 'if (err < 0)'.
      The only legitimate user I could find that we get a warning for
      is the (32-bit only) freescale fman driver, so I did not remove
      the IS_ERR_VALUE() there but changed the type to 'unsigned long'.
      For 9pfs, I just worked around one user whose calling conventions
      are so obscure that I did not dare change the behavior.
      
      I was using this definition for testing:
      
       #define IS_ERR_VALUE(x) ((unsigned long*)NULL == (typeof (x)*)NULL && \
             unlikely((unsigned long long)(x) >= (unsigned long long)(typeof(x))-MAX_ERRNO))
      
      which ends up making all 16-bit or wider types work correctly with
      the most plausible interpretation of what IS_ERR_VALUE() was supposed
      to return according to its users, but also causes a compile-time
      warning for any users that do not pass an 'unsigned long' argument.
      
      I suggested this approach earlier this year, but back then we ended
      up deciding to just fix the users that are obviously broken. After
      the initial warning that caused me to get involved in the discussion
      (fs/gfs2/dir.c) showed up again in the mainline kernel, Linus
      asked me to send the whole thing again.
      
      [ Updated the 9p parts as per Al Viro  - Linus ]
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Cc: Andrzej Hajda <a.hajda@samsung.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Link: https://lkml.org/lkml/2016/1/7/363
      Link: https://lkml.org/lkml/2016/5/27/486
      Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> # For nvmem part
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      287980e4
  7. 14 5月, 2016 7 次提交
  8. 13 5月, 2016 3 次提交
  9. 12 5月, 2016 4 次提交
  10. 03 5月, 2016 8 次提交
  11. 02 5月, 2016 9 次提交