On Monday 20 January 2014, Srikanth Thokala wrote: > On Fri, Jan 17, 2014 at 9:43 PM, Arnd Bergmann <arnd@xxxxxxxx> wrote: > > On Thursday 16 January 2014, Srikanth Thokala wrote: > > I also assume that some of the properties should just go away: > > > > * xlnx,device-id should be the argument in the handle from the slave device > > We can have multiple instances of this VDMA IP configured in the FPGA and we > need a unique identifier for each VDMA device that is present in the FPGA. > This device-id dt parameter forms the filter mask for the slave devices. As an > example, this can be used to get a channel of specific VDMA device (assuming > multiple instances) using the API dma_request_channel(). Please note this > is an example of a slave device that doesnt have dt node. That is not a valid scenario: You should not try to support legacy slave devices (without DT) connected to a dma-engine that is initialized using DT. If you still in the progress of converting drivers to DT, you can use auxdata to attach additional information that can be used for those slave devices, but the code should be kept out of the mainline kernel, and I don't want to see it manifest in the bindings. > > * data width should be a property of the slave driver that is configured > > through dma_slave_config(), unless you can have dma engines that only > > support certain a width. > > Yes, this VDMA engine soft IP support only certain widths, which is > configurable during IP synthesis. But what is this property used for in that case? Surely you can't connect a slave device to a dmaengine if the bus width doesn't match. You probably have a point here, but I don't understand it yet. Arnd -- 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
