On Tuesday 29 September 2015 15:18:07 Jon Hunter wrote: > On 29/09/15 13:39, Arnd Bergmann wrote: > > Ok, that makes more sense then. A few questions still: > > > > * Would the admaif in turn provide a #dma-cells and have the real slaves > > hooked up to it? > > I don't think that that would be necessary. If you look at the existing > tegra i2s binding [0], there is a ahub-cif-ids property which maps the > actual slave to the apbif (equivalent of the adma-if). This ID is used > to get the appropriate dma channel for this client interface (cif). > > > * How do you model the xbar in this scenario? > > The xbar is common to existing tegra devices and today is configured via > the ahub-cif-ids property. I see, so instead of modeling the xbar as part of the DMA engine in DT, you model it as part of the slave. This probably adds a bit of complexity and a somewhat nonstandard binding, but it's too late to change that anyway. > > * How does the adma driver know whether you are using a rx or tx channel > > in the above example, should that perhaps be another cell in dma > > specifier? It seems that the numbers are all overlapping between rx and > > tx (each has 1 through 10). > > The channels can be configured to be either rx or tx and yes the IDs do > overlap so you have 1-10 for both rx and tx. However, if you are asking > how do I ensure that only one channel uses a specific hardware request, > then yes I probably need to add the direction to the specifier to ensure > only one channel uses a request at any given time. If each channel is either rx or tx, but the two cannot be used simultaneously, you can just list each of them only once, like this: dmas = <&adma 0>, <&adma 1>, <&adma 2>, ... dma-names = "if0", "if1", "if2", ... Otherwise you end up allocating twice the number of channels that you really need. Arnd -- 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
