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