linux-toradex.git/include/linux/platform_data/dma-dw.h, branch v4.14-rc5

dmaengine: dw: add support of iDMA 32-bit hardware

2017-01-25T06:21:40+00:00

iDMA 32-bit is Intel designed DMA controller that behaves like Synopsys
Designware DMA. This patch adds a support of the new Intel hardware.

Due to iDMA 32-bit has no autoconfiguration the platform code must
provide a platform data to dw_dma_probe().

By default full FIFO (1024 bytes) is assigned to channel 0. Here we
slice FIFO on equal parts between channels for iDMA 32-bit case.

Signed-off-by: Andy Shevchenko 
Signed-off-by: Vinod Koul

dmaengine: DW DMAC: add multi-block property to device tree

2016-11-30T03:27:50+00:00

Several versions of DW DMAC have multi block transfers hardware
support. Hardware support of multi block transfers is disabled
by default if we use DT to configure DMAC and software emulation
of multi block transfers used instead.
Add multi-block property, so it is possible to enable hardware
multi block transfers (if present) via DT.

Switch from per device is_nollp variable to multi_block array
to be able enable/disable multi block transfers separately per
channel.

Acked-by: Andy Shevchenko 
Signed-off-by: Eugeniy Paltsev 
Signed-off-by: Vinod Koul

dmaengine: dw: override LLP support if asked in platform data

2016-08-31T14:13:29+00:00

There are at least two known devices, e.g. DMA controller found on ARC AXS101
SDP board, that have LLP register and no multi block transfer support at the
same time.

Override autodetection by user provided data.

Reported-by: Eugeniy Paltsev 
Reviewed-by: Eugeniy Paltsev 
Signed-off-by: Andy Shevchenko 
Tested-by: Bryan O'Donoghue 
Signed-off-by: Greg Kroah-Hartman

dmaengine: dw: set polarity of handshake interface

2016-08-31T14:13:29+00:00

Intel Quark UART uses DesignWare DMA IP. Though the DMA IP is connected in such
way that handshake interface uses inverted polarity. We have to provide a
possibility to set this in the DMA driver when configuring a channel.

Introduce a new member of custom slave configuration called 'hs_polarity' and
set active low polarity in case this value is 'true'.

Acked-by: Vinod Koul 
Signed-off-by: Andy Shevchenko 
Tested-by: Bryan O'Donoghue 
Signed-off-by: Greg Kroah-Hartman

dmaengine: dw: keep entire platform data in struct dw_dma

2016-05-02T10:01:05+00:00

Keep the entire platform data in the struct dw_dma.
It makes the driver a bit cleaner.

Acked-by: Viresh Kumar 
Signed-off-by: Andy Shevchenko 
Signed-off-by: Vinod Koul

dmaengine: dw: revisit data_width property

2016-05-02T10:00:47+00:00

There several changes are done here:

- Convert the property to be in bytes

  Besides that this is a common practice for such property, the use of a value
  in bytes much more convenient than handling the encoded one.

- Rename data_width to data-width in the device tree bindings

  The change leaves the support for the old format as well just in case someone
  will use a newer kernel with an old device tree blob.

- While here, replace dwc_fast_ffs() by __ffs()

Signed-off-by: Andy Shevchenko 
Acked-by: Viresh Kumar 
Signed-off-by: Vinod Koul

dmaengine: dw: rename masters to reflect actual topology

2016-04-13T16:06:09+00:00

The source and destination masters are reflecting buses or their layers to
where the different devices can be connected. The patch changes the master
names to reflect which one is related to which independently on the transfer
direction.

The outcome of the change is that the memory data width is now always limited
by a data width of the master which is dedicated to communicate to memory.

The patch will not break anything since all current users have the same data
width for all masters. Though it would be nice to revisit avr32 platforms to
check what is the actual hardware topology in use there. It seems that it has
one bus and two masters on it as stated by Table 8-2, that's why everything
works independently on the master in use. The purpose of the sequential patch
is to fix the driver for configuration of more than one bus.

The change is done in the assumption that src_master and dst_master are
reflecting a connection to the memory and peripheral correspondently on avr32
and otherwise on the rest.

Acked-by: Hans-Christian Egtvedt 
Acked-by: Mark Brown 
Signed-off-by: Andy Shevchenko 
Signed-off-by: Vinod Koul

dmaengine: dw: some Intel devices has no memcpy support

2015-10-31T02:02:43+00:00

Provide a flag to choose if the device does support memory-to-memory transfers.
At least this is not true for iDMA32 controller that might be supported in the
future. Besides that Intel BayTrail and Braswell users should not try this
feature due to HW specific behaviour.

Signed-off-by: Andy Shevchenko 
Acked-by: Viresh Kumar 
Signed-off-by: Vinod Koul

dmaengine: dw: define DW_DMA_MAX_NR_MASTERS

2015-02-05T06:39:44+00:00

Instead of using magic number in the code the patch provides
DW_DMA_MAX_NR_MASTERS constant.

While here, restrict the reading of data width array by amount of the actual
number of AHB masters.

Signed-off-by: Andy Shevchenko 
Signed-off-by: Vinod Koul

dmaengine: dw: amend description of dma_dev field

2015-02-05T06:39:43+00:00

The dma_dev field is widely used in filter functions to mach with a proper DMA
controller device. Thus it's not deprecated. The patch fixes the description of
that field. There is no functional change.

Signed-off-by: Andy Shevchenko 
Signed-off-by: Vinod Koul