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. Jon -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
