linux-stable.git/drivers/dma, branch v4.1.26

dmaengine: dw: fix master selection

2016-04-20T05:08:56+00:00

[ Upstream commit 3fe6409c23e2bee4b2b1b6d671d2da8daa15271c ]

The commit 895005202987 ("dmaengine: dw: apply both HS interfaces and remove
slave_id usage") cleaned up the code to avoid usage of depricated slave_id
member of generic slave configuration.

Meanwhile it broke the master selection by removing important call to
dwc_set_masters() in ->device_alloc_chan_resources() which copied masters from
custom slave configuration to the internal channel structure.

Everything works until now since there is no customized connection of
DesignWare DMA IP to the bus, i.e. one bus and one or more masters are in use.
The configurations where 2 masters are connected to the different masters are
not working anymore. We are expecting one user of such configuration and need
to select masters properly. Besides that it is obviously a performance
regression since only one master is in use in multi-master configuration.

Select masters in accordance with what user asked for. Keep this patch in a form
more suitable for back porting.

We are safe to take necessary data in ->device_alloc_chan_resources() because
we don't support generic slave configuration embedded into custom one, and thus
the only way to provide such is to use the parameter to a filter function which
is called exactly before channel resource allocation.

While here, replase BUG_ON to less noisy dev_warn() and prevent channel
allocation in case of error.

Fixes: 895005202987 ("dmaengine: dw: apply both HS interfaces and remove slave_id usage")
Cc: stable@vger.kernel.org
Signed-off-by: Andy Shevchenko 
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin

dmaengine: hsu: correct use of channel status register

2016-04-20T05:03:44+00:00

[ Upstream commit 4f4bc0abff79dc9d7ccbd3143adbf8ad1f4fe6ab ]

There is a typo in documentation regarding to descriptor empty bit (DESCE)
which is set to 1 when descriptor is empty. Thus, status register at the end of
a transfer usually returns all DESCE bits set and thus it will never be zero.

Moreover, there are 2 bits (CDESC) that encode current descriptor, on which
interrupt has been asserted. In case when we have few descriptors programmed we
might have non-zero value.

Remove DESCE and CDESC bits from DMA channel status register (HSU_CH_SR) when
reading it.

Fixes: 2b49e0c56741 ("dmaengine: append hsu DMA driver")
Cc: stable@vger.kernel.org
Signed-off-by: Andy Shevchenko 
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin

dmaengine: at_xdmac: fix residue computation

2016-03-22T15:10:35+00:00

[ Upstream commit 25c5e9626ca4d40928dc9c44f009ce2ed0a739e7 ]

When computing the residue we need two pieces of information: the current
descriptor and the remaining data of the current descriptor. To get
that information, we need to read consecutively two registers but we
can't do it in an atomic way. For that reason, we have to check manually
that current descriptor has not changed.

Signed-off-by: Ludovic Desroches 
Suggested-by: Cyrille Pitchen 
Reported-by: David Engraf 
Tested-by: David Engraf 
Fixes: e1f7c9eee707 ("dmaengine: at_xdmac: creation of the atmel
eXtended DMA Controller driver")
Cc: stable@vger.kernel.org #4.1 and later
Signed-off-by: Vinod Koul 

Signed-off-by: Sasha Levin

dmaengine: dw: disable BLOCK IRQs for non-cyclic xfer

2016-03-04T15:25:43+00:00

[ Upstream commit ee1cdcdae59563535485a5f56ee72c894ab7d7ad ]

The commit 2895b2cad6e7 ("dmaengine: dw: fix cyclic transfer callbacks")
re-enabled BLOCK interrupts with regard to make cyclic transfers work. However,
this change becomes a regression for non-cyclic transfers as interrupt counters
under stress test had been grown enormously (approximately per 4-5 bytes in the
UART loop back test).

Taking into consideration above enable BLOCK interrupts if and only if channel
is programmed to perform cyclic transfer.

Fixes: 2895b2cad6e7 ("dmaengine: dw: fix cyclic transfer callbacks")
Signed-off-by: Andy Shevchenko 
Acked-by: Mans Rullgard 
Tested-by: Mans Rullgard 
Acked-by: Viresh Kumar 
Cc: 
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin

dmaengine: at_xdmac: fix resume for cyclic transfers

2016-02-03T21:23:19+00:00

[ Upstream commit 611dcadb01c89d1d3521450c05a4ded332e5a32d ]

When having cyclic transfers, the channel was paused when performing
suspend but was not correctly resumed.

Signed-off-by: Songjun Wu 
Signed-off-by: Ludovic Desroches 
Fixes: e1f7c9eee707 ("dmaengine: at_xdmac: creation of the atmel
eXtended DMA Controller driver")
Cc:  # 4.1 and later
Signed-off-by: Vinod Koul 

Signed-off-by: Sasha Levin

dmaengine: dw: fix cyclic transfer callbacks

2016-02-03T21:23:14+00:00

[ Upstream commit 2895b2cad6e7a95104cf396e5330054453382ae1 ]

Cyclic transfer callbacks rely on block completion interrupts which were
disabled in commit ff7b05f29fd4 ("dmaengine/dw_dmac: Don't handle block
interrupts").  This re-enables block interrupts so the cyclic callbacks
can work.  Other transfer types are not affected as they set the INT_EN
bit only on the last block.

Fixes: ff7b05f29fd4 ("dmaengine/dw_dmac: Don't handle block interrupts")
Signed-off-by: Mans Rullgard 
Reviewed-by: Viresh Kumar 
Signed-off-by: Vinod Koul 
Cc: 
Signed-off-by: Sasha Levin

dmaengine: dw: fix cyclic transfer setup

2016-02-03T21:23:14+00:00

[ Upstream commit df3bb8a0e619d501cd13334c3e0586edcdcbc716 ]

Commit 61e183f83069 ("dmaengine/dw_dmac: Reconfigure interrupt and
chan_cfg register on resume") moved some channel initialisation to
a new function which must be called before starting a transfer.

This updates dw_dma_cyclic_start() to use dwc_dostart() like the other
modes, thus ensuring dwc_initialize() gets called and removing some code
duplication.

Fixes: 61e183f83069 ("dmaengine/dw_dmac: Reconfigure interrupt and chan_cfg register on resume")
Signed-off-by: Mans Rullgard 
Reviewed-by: Viresh Kumar 
Signed-off-by: Vinod Koul 
Cc: 
Signed-off-by: Sasha Levin

dmaengine: dw: properly read DWC_PARAMS register

2015-10-22T21:43:13+00:00

commit 6bea0f6d1c47b07be88dfd93f013ae05fcb3d8bf upstream.

In case we have less than maximum allowed channels (8) and autoconfiguration is
enabled the DWC_PARAMS read is wrong because it uses different arithmetic to
what is needed for channel priority setup.

Re-do the caclulations properly. This now works on AVR32 board well.

Fixes: fed2574b3c9f (dw_dmac: introduce software emulation of LLP transfers)
Cc: yitian.bu@tangramtek.com
Signed-off-by: Andy Shevchenko 
Signed-off-by: Vinod Koul 
Signed-off-by: Greg Kroah-Hartman

dmaengine: at_xdmac: fix transfer data width in at_xdmac_prep_slave_sg()

2015-08-17T03:52:16+00:00

commit 1c8a38b1268aebc1a903b21b11575077e02d2cf7 upstream.

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: Cyrille Pitchen 
Fixes: 6d3a7d9e3ada ("dmaengine: at_xdmac: allow muliple dwidths when doing slave transfers")
Cc: stable@vger.kernel.org #4.0 and later
Acked-by: Nicolas Ferre 
Acked-by: Ludovic Desroches 
Signed-off-by: Vinod Koul 
Signed-off-by: Greg Kroah-Hartman

dmaengine: pl330: Really fix choppy sound because of wrong residue calculation

2015-08-17T03:52:11+00:00

commit 5dd90e5b91e0f5c925b12b132c7cd27538870256 upstream.

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: Krzysztof Kozlowski 
Fixes: aee4d1fac887 ("dmaengine: pl330: improve pl330_tx_status() function")
Reported-by: gabriel@unseen.is
Suggested-by: Marek Szyprowski 
Tested-by: Lars-Peter Clausen 
Signed-off-by: Vinod Koul 
Signed-off-by: Greg Kroah-Hartman