[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-tegra
Subject:    Re: [PATCH 3/3] dmaengine: tegra-adma: Add support for Tegra210 ADMA
From:       Stephen Warren <swarren () wwwdotorg ! org>
Date:       2015-09-30 16:37:44
Message-ID: 560C0FD8.3050204 () wwwdotorg ! org
[Download RAW message or body]

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 linux-tegra" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]