Skip to content
  1. Jul 31, 2015
    • Thomas Petazzoni's avatar
      dmaengine: mv_xor: fix big endian operation in register mode · 0ec9ebc7
      Thomas Petazzoni authored 
      Commit 6f166312 ("dmaengine: mv_xor: add support for a38x command
in descriptor mode") introduced the support for a feature that
appeared in Armada 38x: specifying the operation to be performed in a
per-descriptor basis rather than globally per channel.

However, when doing so, it changed the function mv_chan_set_mode() to
use:

  if (IS_ENABLED(__BIG_ENDIAN))

instead of:

  #if defined(__BIG_ENDIAN)

While IS_ENABLED() is perfectly fine for CONFIG_* symbols, it is not
for other symbols such as __BIG_ENDIAN that is provided directly by
the compiler. Consequently, the commit broke support for big-endian,
as the XOR_DESCRIPTOR_SWAP flag was not set in the XOR channel
configuration register.

The primarily visible effect was some nasty warnings and failures
appearing during the self-test of the XOR unit:

[    1.197368] mv_xor d0060900.xor: error on chan 0. intr cause 0x00000082
[    1.197393] mv_xor d0060900.xor: config       0x00008440
[    1.197410] mv_xor d0060900.xor: activation   0x00000000
[    1.197427] mv_xor d0060900.xor: intr cause   0x00000082
[    1.197443] mv_xor d0060900.xor: intr mask    0x000003f7
[    1.197460] mv_xor d0060900.xor: error cause  0x00000000
[    1.197477] mv_xor d0060900.xor: error addr   0x00000000
[    1.197491] ------------[ cut here ]------------
[    1.197513] WARNING: CPU: 0 PID: 1 at ../drivers/dma/mv_xor.c:664 mv_xor_interrupt_handler+0x14c/0x170()

See also:

  http://storage.kernelci.org/next/next-20150617/arm-mvebu_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y/lab-khilman/boot-armada-xp-openblocks-ax3-4.txt



Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Fixes: 6f166312

 ("dmaengine: mv_xor: add support for a38x command in descriptor mode")
Reviewed-by: default avatarMaxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      0ec9ebc7
    • Rameshwar Prasad Sahu's avatar
      dmaengine: xgene-dma: Fix the resource map to handle overlapping · cda8e937
      Rameshwar Prasad Sahu authored 
      

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: default avatarRameshwar Prasad Sahu <rsahu@apm.com>
Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      cda8e937
    • 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
    • Cyrille Pitchen's avatar
      dmaengine: at_hdmac: fix residue computation · 93dce3a6
      Cyrille Pitchen authored 
      

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: default avatarCyrille Pitchen <cyrille.pitchen@atmel.com>
Acked-by: default avatarTorsten Fleischer <torfl6749@gmail.com>
Tested-by: default avatarJirí Prchal <jiri.prchal@aksignal.cz>
Acked-by: default avatarNicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      93dce3a6
    • 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
  3. Jul 07, 2015
    • Krzysztof Kozlowski's avatar
      dmaengine: pl330: Really fix choppy sound because of wrong residue calculation · 5dd90e5b
      Krzysztof Kozlowski authored 
      

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: default avatarKrzysztof Kozlowski <k.kozlowski.k@gmail.com>
Fixes: aee4d1fa

 ("dmaengine: pl330: improve pl330_tx_status() function")
Cc: <stable@vger.kernel.org>
Reported-by: default avatar <gabriel@unseen.is>
Suggested-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
Tested-by: default avatarLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      5dd90e5b
    • Krzysztof Kozlowski's avatar
      dmaengine: pl330: Fix overflow when reporting residue in memcpy · ae128293
      Krzysztof Kozlowski authored 
      

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: default avatarKrzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: <stable@vger.kernel.org>
Fixes: aee4d1fa

 ("dmaengine: pl330: improve pl330_tx_status() function")
Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      ae128293
  5. Jul 06, 2015
    • Linus Torvalds's avatar
      Linux 4.2-rc1 · d770e558
      Linus Torvalds authored
      d770e558
    • Linus Torvalds's avatar
      Merge tag 'platform-drivers-x86-v4.2-2' of... · a585d2b7
      Linus Torvalds authored 
      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
  7. Jul 05, 2015