linux-stable.git/drivers/dma, branch v3.16.4

dmaengine: dw: don't perform DMA when dmaengine_submit is called

2014-10-05T20:41:11+00:00

commit dd8ecfcac66b4485416b2d1df0ec4798b198d7d6 upstream.

Accordingly to discussion [1] and followed up documentation the DMA controller
driver shouldn't start any DMA operations when dmaengine_submit() is called.

This patch fixes the workflow in dw_dmac driver to follow the documentation.

[1] http://www.spinics.net/lists/arm-kernel/msg125987.html

Signed-off-by: Andy Shevchenko 
Signed-off-by: Vinod Koul 
Cc: "Petallo, MauriceX R" 
Signed-off-by: Greg Kroah-Hartman

dmaengine: dw: introduce dwc_dostart_first_queued() helper

2014-10-05T20:41:11+00:00

commit e7637c6c0382485f4d2e20715d058dae6f2b6a7c upstream.

We have a duplicate code which starts first descriptor in the queue. Let's make
this as a separate helper that can be used in future as well.

Signed-off-by: Andy Shevchenko 
Signed-off-by: Vinod Koul 
Cc: "Petallo, MauriceX R" 
Signed-off-by: Greg Kroah-Hartman

Update imx-sdma cyclic handling to report residue

2014-07-01T06:53:42+00:00

I received a report this morning from one of the Novena developers that
the behaviour of the iMX6 ASoC codec driver (using imx-pcm-dma.c) was
sub-optimal under high system load.

While there are issues relating to system load remaining, upon reviewing
the ASoC imx-pcm-dma.c driver, it was noticed that it not using the
residue support, because SDMA doesn't support it.  This has the effect
that SDMA has to make multiple calls into the ASoC and ALSA code, one
for each period.

Since ALSA's snd_pcm_elapsed() does not need to be called multiple times
and it is entirely sufficient to call it once to update ALSA with the
current buffer position via the pointer method, we can do better here.
We can also avoid stopping the DMA entirely, just like real cyclic DMA
implementations behave.  While this means that we replay some old samples,
this is a nicer behaviour than having audio stop and restart.

The changes to achieve this are relatively minor - imx-sdma.c can track
where the DMA is to the nearest descriptor boundary - it does this
already when deciding how many callbacks to issue.  In doing this,
buf_tail always points at the descriptor which will complete next.

The residue is defined by the bytes remaining to the end of the buffer,
when the buffer is viewed as a single block of memory [start...end].
So, when we start out, there's a full buffer worth of residue, and this
counts down as we approach the end of the buffer, eventually becoming
zero at the end, before returning to the full buffer worth when we
wrap back to the start.

Moving the walking of the descriptors into the interrupt handler means
that we can update the BD_DONE flag at interrupt time, thus avoiding
a delayed tasklet stopping the cyclic DMA.

This means that the residue can be calculated from (total descriptors -
buf_tail) * descriptor size.  This is what the change below does.  We
update imx-pcm-dma.c to remove the NO_RESIDUE flag since we now provide
the residue.

Signed-off-by: Russell King 
Tested-by: Shawn Guo 
Signed-off-by: Vinod Koul

dma: cppi41: handle 0-length packets

2014-07-01T06:45:48+00:00

When a 0-length packet is received on the bus, desc->pd0 yields 1,
which confuses the driver's users. This information is clearly wrong
and not in accordance to the datasheet, but it's been observed on an
AM335x board, very reproducible.

Fix this by looking at bit 19 in PD2 of the completed packet. This bit
will tell us if a zero-length packet was received on a queue. If it's
set, ignore the value in PD0 and report a total length of 0 instead.

Signed-off-by: Daniel Mack 
Signed-off-by: Vinod Koul

Merge branch 'for-linus' of git://git.infradead.org/users/vkoul/slave-dma

2014-06-10T17:28:45+00:00

Pull slave-dmaengine updates from Vinod Koul:
 - new Xilixn VDMA driver from Srikanth
 - bunch of updates for edma driver by Thomas, Joel and Peter
 - fixes and updates on dw, ste_dma, freescale, mpc512x, sudmac etc

* 'for-linus' of git://git.infradead.org/users/vkoul/slave-dma: (45 commits)
  dmaengine: sh: don't use dynamic static allocation
  dmaengine: sh: fix print specifier warnings
  dmaengine: sh: make shdma_prep_dma_cyclic static
  dmaengine: Kconfig: Update MXS_DMA help text to include MX6Q/MX6DL
  of: dma: Grammar s/requests/request/, s/used required/required/
  dmaengine: shdma: Enable driver compilation with COMPILE_TEST
  dmaengine: rcar-hpbdma: Include linux/err.h
  dmaengine: sudmac: Include linux/err.h
  dmaengine: sudmac: Keep #include sorted alphabetically
  dmaengine: shdmac: Include linux/err.h
  dmaengine: shdmac: Keep #include sorted alphabetically
  dmaengine: s3c24xx-dma: Add cyclic transfer support
  dmaengine: s3c24xx-dma: Process whole SG chain
  dmaengine: imx: correct sdmac->status for cyclic dma tx
  dmaengine: pch: fix compilation for alpha target
  dmaengine: dw: check return code of dma_async_device_register()
  dmaengine: dw: fix regression in dw_probe() function
  dmaengine: dw: enable clock before access
  dma: pch_dma: Fix Kconfig dependencies
  dmaengine: mpc512x: add support for peripheral transfers
  ...

Merge branch 'topic/xilinx' into for-linus

2014-06-09T16:26:29+00:00

Merge branch 'topic/dw' into for-linus

2014-06-09T16:25:40+00:00

dmaengine: sh: don't use dynamic static allocation

2014-06-03T06:05:33+00:00

dynamic stack allocation in kernel is considered bad as kernel stack is low and
we get warns on few archs as reported by kbuild test robot

>> drivers/dma/sh/shdma-base.c:671:32: sparse: Variable length array is used.
>> drivers/dma/sh/shdma-base.c:701:1: warning: 'shdma_prep_dma_cyclic' uses
>> dynamic stack allocation [enabled by default]

Fix this by making a static array of 32 which should be sufficient for
shdma_prep_dma_cyclic which only user in kernel is audio and 32 periods for
audio seems quite sufficient atm

Reported-by: kbuild test robot 
Signed-off-by: Vinod Koul

dmaengine: sh: fix print specifier warnings

2014-06-03T06:05:24+00:00

As documented in Documentation/printk-formats.txt we should use %zu/%zx
specifiers for size_t type variables for the code to compile on different
architectures. This is uncovered as COMPILE_TEST has been enabled recently for
this driver

   drivers/dma/sh/shdma-base.c: In function 'shdma_prep_dma_cyclic':
>> drivers/dma/sh/shdma-base.c:683:4: warning: format '%d' expects argument of
>> type 'int', but argument 4 has type 'size_t' [-Wformat=]
       __func__, buf_len, period_len, slave_id);
>> drivers/dma/sh/shdma-base.c:683:4: warning: format '%d' expects argument of
>> type 'int', but argument 5 has type 'size_t' [-Wformat=]

Reported-by: kbuild test robot 
Acked-by: Laurent Pinchart 
Signed-off-by: Vinod Koul

dmaengine: sh: make shdma_prep_dma_cyclic static

2014-06-03T06:04:47+00:00

kbuild test robot reports that shdma_prep_dma_cyclic should be static, since
symbol is not declared, quick check revails that is the case

>> drivers/dma/sh/shdma-base.c:660:32: sparse: symbol 'shdma_prep_dma_cyclic'
>> was not declared. Should it be static?

Reported-by: kbuild test robot 
Acked-by: Laurent Pinchart 
Signed-off-by: Vinod Koul