Re: [PATCH 3/3] dmaengine: tegra-adma: Add support for Tegra210 ADMA

[Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>]

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