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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 09/29/2015 09:34 AM, Arnd Bergmann wrote:
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.

The XBAR shouldn't be modelled as part of the DMA engine; it's something entirely separate.

The data flow (for TX) is:

There's a FIFO in the ADMA-IF. This has a register address. That address can be written to by either PIO (CPU writes) or a DMA engine (in which case a "request selector" is used to communicate flow control information from the ADMI-IF to the DMA engine). Any DMA engine that may be used to write into this FIFO is an entirely separate HW module from the ADMA-IF itself.

The ADMA-IF HW drains data from this FIFO and pushes it into the XBAR. ADMA-IF is an XBAR data source.

The XBAR is a programmable cross-bar matrix. Many sinks are attached to it such as I2S, SPDIF, SRC (sample rate converters), mux/demux, etc. The data flow within the XBAR is purely in logic or internal RAM/flops. There is no transfer to/from DRAM within the XBAR.

For each XBAR sink, the XBAR has registers to select which XBAR source provides data to it.

Thus the ADMA-IF is a DMA sink, and XBAR is unrelated to DMA; it's simply part of the HW processing of the data once it gets into the ADMA-IF.

The RX flow is essentially the same in reverse; the I2S RX being an XBAR source, and a second FIFO in the ADMA-IF being an XBAR sink.
--
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



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux