1. 31 7月, 2015 4 次提交
    • R
      dmaengine: xgene-dma: Fix the resource map to handle overlapping · cda8e937
      Rameshwar Prasad Sahu 提交于
      There is an overlap in dma ring cmd csr region due to sharing of ethernet
      ring cmd csr region. This patch fix the resource overlapping by mapping
      the entire dma ring cmd csr region.
      Signed-off-by: NRameshwar Prasad Sahu <rsahu@apm.com>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      cda8e937
    • C
      dmaengine: at_xdmac: fix transfer data width in at_xdmac_prep_slave_sg() · 1c8a38b1
      Cyrille Pitchen 提交于
      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: NCyrille 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: NNicolas Ferre <nicolas.ferre@atmel.com>
      Acked-by: NLudovic Desroches <ludovic.desroches@atmel.com>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      1c8a38b1
    • C
      dmaengine: at_hdmac: fix residue computation · 93dce3a6
      Cyrille Pitchen 提交于
      As claimed by the programmer datasheet and confirmed by the IP designer,
      the Block Transfer Size (BTSIZE) bitfield of the Channel x Control A
      Register (CTRLAx) always refers to a number of Source Width (SRC_WIDTH)
      transfers.
      
      Both the SRC_WIDTH and BTSIZE bitfields can be extacted from the CTRLAx
      register to compute the DMA residue. So the 'tx_width' field is useless
      and can be removed from the struct at_desc.
      
      Before this patch, atc_prep_slave_sg() was not consistent: BTSIZE was
      correctly initialized according to the SRC_WIDTH but 'tx_width' was always
      set to reg_width, which was incorrect for MEM_TO_DEV transfers. It led to
      bad DMA residue when 'tx_width' != SRC_WIDTH.
      
      Also the 'tx_width' field was mostly set only in the first and last
      descriptors. Depending on the kind of DMA transfer, this field remained
      uninitialized for intermediate descriptors. The accurate DMA residue was
      computed only when the currently processed descriptor was the first or the
      last of the chain. This algorithm was a little bit odd. An accurate DMA
      residue can always be computed using the SRC_WIDTH and BTSIZE bitfields
      in the CTRLAx register.
      
      Finally, the test to check whether the currently processed descriptor is
      the last of the chain was wrong: for cyclic transfer, last_desc->lli.dscr
      is NOT equal to zero, since set_desc_eol() is never called, but logically
      equal to first_desc->txd.phys. This bug has a side effect on the
      drivers/tty/serial/atmel_serial.c driver, which uses cyclic DMA transfer
      to receive data. Since the DMA residue was wrong each time the DMA
      transfer reaches the second (and last) period of the transfer, no more
      data were received by the USART driver till the cyclic DMA transfer loops
      back to the first period.
      Signed-off-by: NCyrille Pitchen <cyrille.pitchen@atmel.com>
      Acked-by: NTorsten Fleischer <torfl6749@gmail.com>
      Tested-by: NJirí Prchal <jiri.prchal@aksignal.cz>
      Acked-by: NNicolas Ferre <nicolas.ferre@atmel.com>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      93dce3a6
    • L
      dmaengine: at_xdmac: fix bug about channel configuration · 20cadcb4
      Ludovic Desroches 提交于
      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: NLudovic Desroches <ludovic.desroches@atmel.com>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      20cadcb4
  2. 07 7月, 2015 2 次提交
    • K
      dmaengine: pl330: Really fix choppy sound because of wrong residue calculation · 5dd90e5b
      Krzysztof Kozlowski 提交于
      When pl330 driver was used during sound playback, after some time or
      after a number of plays the sound became choppy or totally noisy. For
      example on Odroid XU3 board the first four executions of aplay with
      small WAVE worked fine, but fifth was unrecognizable with errors:
      	$ aplay /usr/share/sounds/alsa/Front_Right.wava
      	underrun!!! (at least 0.095 ms long)
      
      Issue was caused by wrong residue reported by pl330 driver to
      pcm_dmaengine for its cyclic dma transfers.
      
      The pl330_tx_status(), residue reporting function, used a "last" flag in
      a descriptor to indicate that there is no more data to send.
      
      The pl330_tx_submit() iterated over descriptors trying to remove this
      flag from them and then mark last descriptor as "last".  However when
      iterating it actually removed the flag not from descriptors but always
      from last of it (and then reset it). Thus effectively once some
      descriptor was marked as last, then it stayed like this forever causing
      residue to be reported too low.
      Signed-off-by: NKrzysztof Kozlowski <k.kozlowski.k@gmail.com>
      Fixes: aee4d1fa ("dmaengine: pl330: improve pl330_tx_status() function")
      Cc: <stable@vger.kernel.org>
      Reported-by: gabriel@unseen.is
      Suggested-by: NMarek Szyprowski <m.szyprowski@samsung.com>
      Tested-by: NLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      5dd90e5b
    • K
      dmaengine: pl330: Fix overflow when reporting residue in memcpy · ae128293
      Krzysztof Kozlowski 提交于
      During memcpy operations the residue was always set to an u32 overflowed
      value.
      
      In pl330_tx_status() function number of currently transferred bytes was
      subtracted from internal "bytes_requested" field. However this
      "bytes_requested" was not initialized at start to length of memcpy
      buffer so transferred bytes were subtracted from 0 causing overflow.
      Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Cc: <stable@vger.kernel.org>
      Fixes: aee4d1fa ("dmaengine: pl330: improve pl330_tx_status() function")
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      ae128293
  3. 06 7月, 2015 2 次提交
    • L
      Linux 4.2-rc1 · d770e558
      Linus Torvalds 提交于
      d770e558
    • L
      Merge tag 'platform-drivers-x86-v4.2-2' of... · a585d2b7
      Linus Torvalds 提交于
      Merge tag 'platform-drivers-x86-v4.2-2' of git://git.infradead.org/users/dvhart/linux-platform-drivers-x86
      
      Pull late x86 platform driver updates from Darren Hart:
       "The following came in a bit later and I wanted them to bake in next a
        few more days before submitting, thus the second pull.
      
        A new intel_pmc_ipc driver, a symmetrical allocation and free fix in
        dell-laptop, a couple minor fixes, and some updated documentation in
        the dell-laptop comments.
      
        intel_pmc_ipc:
         - Add Intel Apollo Lake PMC IPC driver
      
        tc1100-wmi:
         - Delete an unnecessary check before the function call "kfree"
      
        dell-laptop:
         - Fix allocating & freeing SMI buffer page
         - Show info about WiGig and UWB in debugfs
         - Update information about wireless control"
      
      * tag 'platform-drivers-x86-v4.2-2' of git://git.infradead.org/users/dvhart/linux-platform-drivers-x86:
        intel_pmc_ipc: Add Intel Apollo Lake PMC IPC driver
        tc1100-wmi: Delete an unnecessary check before the function call "kfree"
        dell-laptop: Fix allocating & freeing SMI buffer page
        dell-laptop: Show info about WiGig and UWB in debugfs
        dell-laptop: Update information about wireless control
      a585d2b7
  4. 05 7月, 2015 32 次提交