1. 03 Sep, 2018 1 commit
  2. 22 Apr, 2018 1 commit
  3. 27 Mar, 2018 1 commit
    • Maxime Jayat's avatar
      dmaengine: at_xdmac: fix rare residue corruption · c5637476
      Maxime Jayat authored
      Despite the efforts made to correctly read the NDA and CUBC registers,
      the order in which the registers are read could sometimes lead to an
      inconsistent state.
      
      Re-using the timeline from the comments, this following timing of
      registers reads could lead to reading NDA with value "@desc2" and
      CUBC with value "MAX desc1":
      
       INITD --------                    ------------
                    |____________________|
             _______________________  _______________
       NDA       @desc2             \/   @desc3
             _______________________/\_______________
             __________  ___________  _______________
       CUBC       0    \/ MAX desc1 \/  MAX desc2
             __________/\___________/\_______________
              |  |          |  |
      Events:(1)(2)        (3)(4)
      
      (1) check_nda = @desc2
      (2) initd = 1
      (3) cur_ubc = MAX desc1
      (4) cur_nda = @desc2
      
      This is allowed by the condition ((check_nda == cur_nda) && initd),
      despite cur_ubc and cur_nda being in the precise state we don't want.
      
      This error leads to incorrect residue computation.
      
      Fix it by inversing the order in which CUBC and INITD are read. This
      makes sure that NDA and CUBC are always read together either _before_
      INITD goes to 0 or _after_ it is back at 1.
      The case where NDA is read before INITD is at 0 and CUBC is read after
      INITD is back at 1 will be rejected by check_nda and cur_nda being
      different.
      
      Fixes: 53398f48 ("dmaengine: at_xdmac: fix residue corruption")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarMaxime Jayat <maxime.jayat@mobile-devices.fr>
      Acked-by: default avatarLudovic Desroches <ludovic.desroches@microchip.com>
      Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      c5637476
  4. 21 Aug, 2017 2 commits
  5. 06 Dec, 2016 1 commit
  6. 30 Nov, 2016 1 commit
  7. 22 Aug, 2016 1 commit
  8. 08 Aug, 2016 1 commit
  9. 30 Jun, 2016 1 commit
  10. 08 Jun, 2016 1 commit
  11. 30 May, 2016 3 commits
  12. 10 Mar, 2016 1 commit
  13. 18 Jan, 2016 1 commit
  14. 10 Dec, 2015 1 commit
  15. 05 Dec, 2015 5 commits
  16. 16 Nov, 2015 1 commit
    • Arnd Bergmann's avatar
      dmaengine: at_xdmac: use %pad format string for dma_addr_t · 268914f4
      Arnd Bergmann authored
      dma_addr_t may be defined as 32 or 64 bit depending on configuration,
      so it cannot be printed using the normal format strings, as
      gcc correctly warns:
      
      drivers/dma/at_xdmac.c: In function 'at_xdmac_interleaved_queue_desc':
      drivers/dma/at_xdmac.c:922:51: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t {aka long long unsigned int}' [-Wformat=]
      
      This changes the format strings to use the special "%pad" format
      string that prints a dma_addr_t, and changes the arguments so we
      pass the address by reference as required.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      268914f4
  17. 01 Oct, 2015 4 commits
  18. 19 Aug, 2015 1 commit
  19. 06 Aug, 2015 1 commit
  20. 31 Jul, 2015 2 commits
    • Cyrille Pitchen's avatar
      dmaengine: at_xdmac: fix transfer data width in at_xdmac_prep_slave_sg() · 1c8a38b1
      Cyrille Pitchen authored
      This patch adds the missing update of the transfer data width in
      at_xdmac_prep_slave_sg().
      
      Indeed, for each item in the scatter-gather list, we check whether the
      transfer length is aligned with the data width provided by
      dmaengine_slave_config(). If so, we directly use this data width for the
      current part of the transfer we are preparing. Otherwise, the data width
      is reduced to 8 bits (1 byte). Of course, the actual number of register
      accesses must also be updated to match the new data width.
      
      So one chunk was missing in the original patch (see Fixes tag below): the
      number of register accesses was correctly set to (len >> fixed_dwidth) in
      mbr_ubc but the real data width was not updated in mbr_cfg. Since mbr_cfg
      may change for each part of the scatter-gather transfer this also explains
      why the original patch used the Descriptor View 2 instead of the
      Descriptor View 1.
      
      Let's take the example of a DMA transfer to write 8bit data into an Atmel
      USART with FIFOs. When FIFOs are enabled in the USART, its Transmit
      Holding Register (THR) works in multidata mode, that is to say that up to
      4 8bit data can be written into the THR in a single 32bit access and it is
      still possible to write only one data with a 8bit access. To take
      advantage of this new feature, the DMA driver was modified to allow
      multiple dwidths when doing slave transfers.
      For instance, when the total length is 22 bytes, the USART driver splits
      the transfer into 2 parts:
      
      First part: 20 bytes transferred through 5 32bit writes into THR
      Second part: 2 bytes transferred though 2 8bit writes into THR
      
      For the second part, the data width was first set to 4_BYTES by the USART
      driver thanks to dmaengine_slave_config() then at_xdmac_prep_slave_sg()
      reduces this data width to 1_BYTE because the 2 byte length is not aligned
      with the original 4_BYTES data width. Since the data width is modified,
      the actual number of writes into THR must be set accordingly.
      Signed-off-by: default avatarCyrille Pitchen <cyrille.pitchen@atmel.com>
      Fixes: 6d3a7d9e ("dmaengine: at_xdmac: allow muliple dwidths when doing slave transfers")
      Cc: stable@vger.kernel.org #4.0 and later
      Acked-by: default avatarNicolas Ferre <nicolas.ferre@atmel.com>
      Acked-by: default avatarLudovic Desroches <ludovic.desroches@atmel.com>
      Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      1c8a38b1
    • Ludovic Desroches's avatar
      dmaengine: at_xdmac: fix bug about channel configuration · 20cadcb4
      Ludovic Desroches authored
      When using descriptor view 2 or higher, we don't write the configuration
      into AT_XDMAC_CC register because this configuration will be fetch from
      the descriptor. Unfortunately, the PROT bit is not updated with this
      method, we have to do it manually before enabling the channel.
      Signed-off-by: default avatarLudovic Desroches <ludovic.desroches@atmel.com>
      Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      20cadcb4
  21. 06 Jul, 2015 1 commit
  22. 25 Jun, 2015 1 commit
  23. 12 Jun, 2015 1 commit
  24. 08 Jun, 2015 2 commits
    • Ludovic Desroches's avatar
      dmaengine: at_xdmac: rework slave configuration part · 765c37d8
      Ludovic Desroches authored
      Rework slave configuration part in order to more report wrong errors
      about the configuration.
      Only maxburst and addr width values are checked when doing the slave
      configuration. The validity of the channel configuration is done at
      prepare time.
      Signed-off-by: default avatarLudovic Desroches <ludovic.desroches@atmel.com>
      Cc: stable@vger.kernel.org # 4.0 and later
      Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      765c37d8
    • Ludovic Desroches's avatar
      dmaengine: at_xdmac: lock fixes · 4c374fc7
      Ludovic Desroches authored
      Using _bh variant for spin locks causes this kind of warning:
      Starting logging: ------------[ cut here ]------------
      WARNING: CPU: 0 PID: 3 at /ssd_drive/linux/kernel/softirq.c:151
      __local_bh_enable_ip+0xe8/0xf4()
      Modules linked in:
      CPU: 0 PID: 3 Comm: ksoftirqd/0 Not tainted 4.1.0-rc2+ #94
      Hardware name: Atmel SAMA5
      [<c0013c04>] (unwind_backtrace) from [<c00118a4>] (show_stack+0x10/0x14)
      [<c00118a4>] (show_stack) from [<c001bbcc>]
      (warn_slowpath_common+0x80/0xac)
      [<c001bbcc>] (warn_slowpath_common) from [<c001bc14>]
      (warn_slowpath_null+0x1c/0x24)
      [<c001bc14>] (warn_slowpath_null) from [<c001e28c>]
      (__local_bh_enable_ip+0xe8/0xf4)
      [<c001e28c>] (__local_bh_enable_ip) from [<c01fdbd0>]
      (at_xdmac_device_terminate_all+0xf4/0x100)
      [<c01fdbd0>] (at_xdmac_device_terminate_all) from [<c02221a4>]
      (atmel_complete_tx_dma+0x34/0xf4)
      [<c02221a4>] (atmel_complete_tx_dma) from [<c01fe4ac>]
      (at_xdmac_tasklet+0x14c/0x1ac)
      [<c01fe4ac>] (at_xdmac_tasklet) from [<c001de58>]
      (tasklet_action+0x68/0xb4)
      [<c001de58>] (tasklet_action) from [<c001dfdc>]
      (__do_softirq+0xfc/0x238)
      [<c001dfdc>] (__do_softirq) from [<c001e140>] (run_ksoftirqd+0x28/0x34)
      [<c001e140>] (run_ksoftirqd) from [<c0033a3c>]
      (smpboot_thread_fn+0x138/0x18c)
      [<c0033a3c>] (smpboot_thread_fn) from [<c0030e7c>] (kthread+0xdc/0xf0)
      [<c0030e7c>] (kthread) from [<c000f480>] (ret_from_fork+0x14/0x34)
      ---[ end trace b57b14a99c1d8812 ]---
      
      It comes from the fact that devices can called some code from the DMA
      controller with irq disabled. _bh variant is not intended to be used in
      this case since it can enable irqs. Switch to irqsave/irqrestore variant to
      avoid this situation.
      Signed-off-by: default avatarLudovic Desroches <ludovic.desroches@atmel.com>
      Cc: stable@vger.kernel.org # 4.0 and later
      Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      4c374fc7
  25. 18 May, 2015 4 commits