On 09/25/2015 09:38 AM, Jon Hunter wrote:
On 25/09/15 16:17, Jon Hunter wrote:
On 25/09/15 16:03, Arnd Bergmann wrote:
On Friday 25 September 2015 15:56:40 Jon Hunter wrote:
+ 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.
The channel IDs should be dynamically assigned at run-time.
DT should provide the slave ID (if there is one) for each client.
The two concepts are completely orthogonal.
--
To unsubscribe from this list: send the line "unsubscribe dmaengine" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
