linux-stable.git/drivers/dma, branch v5.9.2

dmaengine: dw: Activate FIFO-mode for memory peripherals only

2020-10-29T09:12:20+00:00

[ Upstream commit 6d9459d04081c796fc67c2bb771f4e4ebb5744c4 ]

CFGx.FIFO_MODE field controls a DMA-controller "FIFO readiness" criterion.
In other words it determines when to start pushing data out of a DW
DMAC channel FIFO to a destination peripheral or from a source
peripheral to the DW DMAC channel FIFO. Currently FIFO-mode is set to one
for all DW DMAC channels. It means they are tuned to flush data out of
FIFO (to a memory peripheral or by accepting the burst transaction
requests) when FIFO is at least half-full (except at the end of the block
transfer, when FIFO-flush mode is activated) and are configured to get
data to the FIFO when it's at least half-empty.

Such configuration is a good choice when there is no slave device involved
in the DMA transfers. In that case the number of bursts per block is less
than when CFGx.FIFO_MODE = 0 and, hence, the bus utilization will improve.
But the latency of DMA transfers may increase when CFGx.FIFO_MODE = 1,
since DW DMAC will wait for the channel FIFO contents to be either
half-full or half-empty depending on having the destination or the source
transfers. Such latencies might be dangerous in case if the DMA transfers
are expected to be performed from/to a slave device. Since normally
peripheral devices keep data in internal FIFOs, any latency at some
critical moment may cause one being overflown and consequently losing
data. This especially concerns a case when either a peripheral device is
relatively fast or the DW DMAC engine is relatively slow with respect to
the incoming data pace.

In order to solve problems, which might be caused by the latencies
described above, let's enable the FIFO half-full/half-empty "FIFO
readiness" criterion only for DMA transfers with no slave device involved.
Thanks to the commit 99ba8b9b0d97 ("dmaengine: dw: Initialize channel
before each transfer") we can freely do that in the generic
dw_dma_initialize_chan() method.

Signed-off-by: Serge Semin 
Reviewed-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/20200731200826.9292-3-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin

dmaengine: dw: Add DMA-channels mask cell support

2020-10-29T09:12:20+00:00

[ Upstream commit e8ee6c8cb61b676f1a2d6b942329e98224bd8ee9 ]

DW DMA IP-core provides a way to synthesize the DMA controller with
channels having different parameters like maximum burst-length,
multi-block support, maximum data width, etc. Those parameters both
explicitly and implicitly affect the channels performance. Since DMA slave
devices might be very demanding to the DMA performance, let's provide a
functionality for the slaves to be assigned with DW DMA channels, which
performance according to the platform engineer fulfill their requirements.
After this patch is applied it can be done by passing the mask of suitable
DMA-channels either directly in the dw_dma_slave structure instance or as
a fifth cell of the DMA DT-property. If mask is zero or not provided, then
there is no limitation on the channels allocation.

For instance Baikal-T1 SoC is equipped with a DW DMAC engine, which first
two channels are synthesized with max burst length of 16, while the rest
of the channels have been created with max-burst-len=4. It would seem that
the first two channels must be faster than the others and should be more
preferable for the time-critical DMA slave devices. In practice it turned
out that the situation is quite the opposite. The channels with
max-burst-len=4 demonstrated a better performance than the channels with
max-burst-len=16 even when they both had been initialized with the same
settings. The performance drop of the first two DMA-channels made them
unsuitable for the DW APB SSI slave device. No matter what settings they
are configured with, full-duplex SPI transfers occasionally experience the
Rx FIFO overflow. It means that the DMA-engine doesn't keep up with
incoming data pace even though the SPI-bus is enabled with speed of 25MHz
while the DW DMA controller is clocked with 50MHz signal. There is no such
problem has been noticed for the channels synthesized with
max-burst-len=4.

Signed-off-by: Serge Semin 
Link: https://lore.kernel.org/r/20200731200826.9292-6-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin

dmaengine: ti: k3-udma-glue: Fix parameters for rx ring pair request

2020-10-29T09:12:02+00:00

[ Upstream commit 6259c8441c4de3f1727a0db61465a8dc8f340c05 ]

The original commit mixed up the forward and completion ring IDs for the
rx flow configuration.

Acked-by: Vinod Koul 
Reviewed-by: Grygorii Strashko 
Fixes: 4927b1ab2047 ("dmaengine: ti: k3-udma: Switch to k3_ringacc_request_rings_pair")
Signed-off-by: Peter Ujfalusi 
Signed-off-by: Santosh Shilimkar 
Signed-off-by: Sasha Levin

dmaengine: ioat: Allocate correct size for descriptor chunk

2020-10-29T09:11:34+00:00

[ Upstream commit 028926e4ac8f21af343c25794117fd13c08b1712 ]

dma_alloc_coherent() is called with a fixed SZ_2M size, but frees happen
with IOAT_CHUNK_SIZE. Recently, IOAT_CHUNK_SIZE was reduced to 512M but
the allocation did not change. To fix, change to using the
IOAT_CHUNK_SIZE define.

This was caught with the upcoming patchset for converting Intel platforms to the
dma-iommu implementation. It has a warning when the unmapped size differs from
the mapped size.

Fixes: a02254f8a676 ("dmaengine: ioat: Decreasing allocation chunk size 2M->512K")
Suggested-by: Robin Murphy 
Signed-off-by: Logan Gunthorpe 
Acked-by: Dave Jiang 
Cc: Vinod Koul 
Cc: Dave Jiang 
Cc: Dan Williams 
Link: https://lore.kernel.org/intel-gfx/776771a2-247a-d1be-d882-bee02d919ae0@deltatee.com/
Link: https://lore.kernel.org/r/20200922200844.2982-1-logang@deltatee.com
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin

dmaengine: dmatest: Check list for emptiness before access its last entry

2020-10-29T09:11:25+00:00

[ Upstream commit b28de385b71abf31ce68ec0387638bee26ae9024 ]

After writing a garbage to the channel we get an Oops in dmatest_chan_set()
due to access to last entry in the empty list.

[  212.670672] BUG: unable to handle page fault for address: fffffff000000020
[  212.677562] #PF: supervisor read access in kernel mode
[  212.682702] #PF: error_code(0x0000) - not-present page
...
[  212.710074] RIP: 0010:dmatest_chan_set+0x149/0x2d0 [dmatest]
[  212.715739] Code: e8 cc f9 ff ff 48 8b 1d 0d 55 00 00 48 83 7b 10 00 0f 84 63 01 00 00 48 c7 c7 d0 65 4d c0 e8 ee 4a f5 e1 48 89 c6 48 8b 43 10 <48> 8b 40 20 48 8b 78 58 48 85 ff 0f 84 f5 00 00 00 e8 b1 41 f5 e1

Fix this by checking list for emptiness before accessing its last entry.

Fixes: d53513d5dc28 ("dmaengine: dmatest: Add support for multi channel testing")
Cc: Vladimir Murzin 
Signed-off-by: Andy Shevchenko 
Tested-by: Peter Ujfalusi 
Link: https://lore.kernel.org/r/20200922115847.30100-2-andriy.shevchenko@linux.intel.com
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin

dmaengine: ti: k3-udma-glue: fix channel enable functions

2020-10-29T09:11:23+00:00

[ Upstream commit 52c74d3d356b60f3c53dc69e5109752347e144e8 ]

Now the K3 UDMA glue layer enable functions perform RMW operation on UDMA
RX/TX RT_CTL registers to set EN bit and enable channel, which is
incorrect, because only EN bit has to be set in those registers to enable
channel (all other bits should be cleared 0).
More over, this causes issues when bootloader leaves UDMA channel RX/TX
RT_CTL registers in incorrect state - TDOWN bit set, for example. As
result, UDMA channel will just perform teardown right after it's enabled.

Hence, fix it by writing correct values (EN=1) directly in UDMA channel
RX/TX RT_CTL registers in k3_udma_glue_enable_tx/rx_chn() functions.

Fixes: d70241913413 ("dmaengine: ti: k3-udma: Add glue layer for non DMAengine users")
Signed-off-by: Grygorii Strashko 
Acked-by: Peter Ujfalusi 
Link: https://lore.kernel.org/r/20200916120955.7963-1-grygorii.strashko@ti.com
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin

dmaengine: dmatest: Prevent to run on misconfigured channel

2020-09-22T14:48:05+00:00

Andy reported that commit 6b41030fdc79 ("dmaengine: dmatest:
Restore default for channel") broke his scripts for the case
where "busy" channel is used for configuration with expectation
that run command would do nothing. Instead, behavior was
(unintentionally) changed to treat such case as under-configuration
and progress with defaults, i.e. run command would start a test
with default setting for channel (which would use all channels).

Restore original behavior with tracking status of channel setter
so we can distinguish between misconfigured and under-configured
cases in run command and act accordingly.

Fixes: 6b41030fdc79 ("dmaengine: dmatest: Restore default for channel")
Reported-by: Andy Shevchenko 
Tested-by: Andy Shevchenko 
Signed-off-by: Vladimir Murzin 
Tested-by: Peter Ujfalusi 
Signed-off-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/20200922115847.30100-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Vinod Koul

Merge tag 'dmaengine-fix-5.9-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine

2020-09-04T19:12:39+00:00

Pull dmaengine fixes from Vinod Koul:
 "A couple of core fixes and odd driver fixes for dmaengine subsystem:

  Core:
   - drop ACPI CSRT table reference after using it
   - fix of_dma_router_xlate() error handling

  Drivers fixes in idxd, at_hdmac, pl330, dw-edma and jz478"

* tag 'dmaengine-fix-5.9-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine:
  dmaengine: ti: k3-udma: Update rchan_oes_offset for am654 SYSFW ABI 3.0
  drivers/dma/dma-jz4780: Fix race condition between probe and irq handler
  dmaengine: dw-edma: Fix scatter-gather address calculation
  dmaengine: ti: k3-udma: Fix the TR initialization for prep_slave_sg
  dmaengine: pl330: Fix burst length if burst size is smaller than bus width
  dmaengine: at_hdmac: add missing kfree() call in at_dma_xlate()
  dmaengine: at_hdmac: add missing put_device() call in at_dma_xlate()
  dmaengine: at_hdmac: check return value of of_find_device_by_node() in at_dma_xlate()
  dmaengine: of-dma: Fix of_dma_router_xlate's of_dma_xlate handling
  dmaengine: idxd: reset states after device disable or reset
  dmaengine: acpi: Put the CSRT table after using it

dmaengine: ti: k3-udma: Update rchan_oes_offset for am654 SYSFW ABI 3.0

2020-09-03T07:23:53+00:00

SYSFW ABI 3.0 has changed the rchan_oes_offset value for am654 to support
SR2.

Since the kernel now needs SYSFW API 3.0 to work because the merged irqchip
update, we need to also update the am654 rchan_oes_offset.

Signed-off-by: Peter Ujfalusi 
Link: https://lore.kernel.org/r/20200831091019.25273-1-peter.ujfalusi@ti.com
Signed-off-by: Vinod Koul

fsldma: fix very broken 32-bit ppc ioread64 functionality

2020-08-29T20:50:56+00:00

Commit ef91bb196b0d ("kernel.h: Silence sparse warning in
lower_32_bits") caused new warnings to show in the fsldma driver, but
that commit was not to blame: it only exposed some very incorrect code
that tried to take the low 32 bits of an address.

That made no sense for multiple reasons, the most notable one being that
that code was intentionally limited to only 32-bit ppc builds, so "only
low 32 bits of an address" was completely nonsensical.  There were no
high bits to mask off to begin with.

But even more importantly fropm a correctness standpoint, turning the
address into an integer then caused the subsequent address arithmetic to
be completely wrong too, and the "+1" actually incremented the address
by one, rather than by four.

Which again was incorrect, since the code was reading two 32-bit values
and trying to make a 64-bit end result of it all.  Surprisingly, the
iowrite64() did not suffer from the same odd and incorrect model.

This code has never worked, but it's questionable whether anybody cared:
of the two users that actually read the 64-bit value (by way of some C
preprocessor hackery and eventually the 'get_cdar()' inline function),
one of them explicitly ignored the value, and the other one might just
happen to work despite the incorrect value being read.

This patch at least makes it not fail the build any more, and makes the
logic superficially sane.  Whether it makes any difference to the code
_working_ or not shall remain a mystery.

Compile-tested-by: Guenter Roeck 
Reviewed-by: Guenter Roeck 
Signed-off-by: Linus Torvalds