Hans-Christian Noren Egtvedt [off-list ref] writes:

Around Sun 24 Jan 2016 20:19:46 +0000 or thereabout, Måns Rullgård wrote:

quoted

Hans-Christian Noren Egtvedt [off-list ref] writes:

quoted

Around Sun 24 Jan 2016 19:21:50 +0000 or thereabout, Mans Rullgard wrote:

quoted

From: Andy Shevchenko <andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>

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 plaforms to
check what is the actual hardware topology is used 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 that one bus.

Not entirely sure what you want to have confirmed here. There are multiple
masters and slaves on the HMATRIX internal bus on AVR32, and the DMA
controller supports up to three simultaneous configurations.

Sounds good to support configuration of more than one bus. I thought we
always did support that? Perhaps it was a non-standard avr32 implementation.

The DW DMA controller on the AT32AP7000 serves the MCI, AC97, and ABDAC
peripherals.  It appears to work regardless of the values put in the
various master select fields.  Perhaps the topology is hardwired in the
DMA controller and those fields are ignored.  The AVR32 works both
before and after this patch series, the main purpose of which (at least
my patches) is to fix the SATA driver on 460EX.

DEST_PER and SRC_PER in the DMA controller selects this, numbers placed here
should match the table you most likely found, 9-3.

Wiring the handshake connections is done with the struct dw_dma_slave src_id
or dst_id member, depending on data direction. Configured in the at32ap700x.c
machine code.

It is not hard wired on avr32, as there are not one-to-one configurations and
masters.

This is about the SMS (Source Master Select) and DMS (Destination Master
Select) fields in the CTLxL register and the LMS (List Master Select)
field in the LLPx register.

quoted

quoted

quoted

The change is done in the assumption that src_master and dst_master are
reflecting a connection to the memory and peripheral correspondently on all
platforms except 460ex.

OK, I have no knowledge about the 460ex.

quoted

quoted

quoted

Signed-off-by: Andy Shevchenko <andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Signed-off-by: Mans Rullgard <redacted>

For the avr32 related stuff:

Acked-by: Hans-Christian Egtvedt <redacted>

quoted

---
 Documentation/devicetree/bindings/dma/snps-dma.txt |  4 ++--
 arch/avr32/mach-at32ap/at32ap700x.c                | 16 ++++++++--------
 drivers/ata/sata_dwc_460ex.c                       |  4 ++--
 drivers/dma/dw/core.c                              | 15 +++++++--------
 drivers/dma/dw/platform.c                          | 12 ++++++------
 drivers/dma/dw/regs.h                              |  4 ++--
 drivers/spi/spi-pxa2xx-pci.c                       |  8 ++++----
 drivers/tty/serial/8250/8250_pci.c                 |  8 ++++----
 include/linux/platform_data/dma-dw.h               |  8 ++++----
 9 files changed, 39 insertions(+), 40 deletions(-)

<snipp diff>

-- 
Best regards, Hans-Christian Egtvedt

-- 
Måns Rullgård
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html