On 29/09/15 13:39, Arnd Bergmann wrote: [snip] > 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. > * 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. Cheers Jon [0] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/sound/nvidia,tegra30-i2s.txt -- 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
