Re: [PATCH 3/3] dmaengine: tegra-adma: Add support for Tegra210 ADMA

On 25/09/15 16:17, Jon Hunter wrote:

On 25/09/15 16:03, Arnd Bergmann wrote:

quoted

On Friday 25 September 2015 15:56:40 Jon Hunter wrote:

quoted

+       case DMA_MEM_TO_DEV:
+               burst_size = fls(tdc->config.dst_maxburst);
+               ch_regs->config = ADMA_CH_CONFIG_SRC_BUF(num_bufs - 1);
+               ch_regs->ctrl = ADMA_CH_CTRL_XFER_DIR(ADMA_MEM_TO_AHUB) |
+                               ADMA_CH_CTRL_TX_REQ(tdc->config.slave_id);
+               ch_regs->src_addr = buf_addr;
+               break;
+
+       case DMA_DEV_TO_MEM:
+               burst_size = fls(tdc->config.src_maxburst);
+               ch_regs->config = ADMA_CH_CONFIG_TRG_BUF(num_bufs - 1);
+               ch_regs->ctrl = ADMA_CH_CTRL_XFER_DIR(ADMA_AHUB_TO_MEM) |
+                               ADMA_CH_CTRL_RX_REQ(tdc->config.slave_id);
+               ch_regs->trg_addr = buf_addr;
+               break;

Do not use the 'slave_id' field here to identify the slave device, that
concept is broken. Instead, put the slave identification into the
dma specifier in DT and read it out in your xlate function.

Why is it broken?

What happens if I don't know the slave-id? In other words, the slave-id
can be dynamically allocated and associated with a given slave.

I guess thinking about it some more, the driver could assign an id
itself to a given channel and I could avoid using slave_id here. There
are 22 channels and 10 tx and 10 rx requests. However, I could also
statically assign a mapping in DT for the clients if that is preferred.

Jon