Date:   Mon, 28 Aug 2017 14:48:50 +0300
From:   Peter Ujfalusi <peter.ujfalusi@...com>
To:     Pierre Yves MORDRET <pierre-yves.mordret@...com>,
        Vinod Koul <vinod.koul@...el.com>
CC:     Mark Rutland <mark.rutland@....com>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        Amelie DELAUNAY <amelie.delaunay@...com>,
        Alexandre TORGUE <alexandre.torgue@...com>,
        Russell King <linux@...linux.org.uk>,
        Fabien DESSENNE <fabien.dessenne@...com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "dmaengine@...r.kernel.org" <dmaengine@...r.kernel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Maxime Coquelin <mcoquelin.stm32@...il.com>,
        "M'boumba Cedric Madianga" <cedric.madianga@...il.com>,
        Dan Williams <dan.j.williams@...el.com>,
        Fabrice GASNIER <fabrice.gasnier@...com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        Herbert Xu <herbert@...dor.apana.org.au>
Subject: Re: [PATCH v3 2/5] dmaengine: Add STM32 DMAMUX driver


Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

On 2017-08-24 16:03, Pierre Yves MORDRET wrote:
> Please tell me whether I'm wrong but for am335x/am437x both DMA Channels and
> events are given by DT. I believe IP Spec provides the mapping for the channel
> (this is what you call fixed channel) and DMA router event is selected randomly
> within the DT.

In our eDMA the channel number and the DMA event number is locked
together. Event 17 can only be serviced by eDMA channel 17. The
am335x/am437x DMA crossbar is implemented on every DMA event lane and by
changing it you can select different event to be routed to the given
event number. The eDMA can handle up to 64 unique DMA events, however
for each of this 64 events we have a crossbar which allows to select
from up to 63 other sources. I can not allocate the eDMA channel in the
crossbar as I can not be sure that I will not step on some other
driver's toe and take a channel (event) which someone want to use with
it's default purpose. So the binding includes the channel number and the
crossbar mapped event ID.

Oh, and this eDMA limitation is the main source of my hassle with the
mem-to-mem channel: in DT we must tell what channels can be used for
memcpy - the ones that are not used on the board (usually we pick i2c
since we don't support DMA with that).

> As for dra7 events comes from DT but channel is selected though out local
> algorithm. IP Spec defines DMA event muxer mapping.

Here it is again a different story. The crossbar in dra7 can handle 256
incoming events and it can map any of these events to the 64 eDMA event
number (or channel) or if it is front of the sDMA we can select the sDMA
event number from the 128 it can handle.

Here we only use the event number in the crossbar node as we will pick
the eDMA event, which is going to be correspond to the eDMA channel.

> At my opinion my router is more closed to dra7. IP Spec defines event mapping.
> Nonetheless the DMA has a fixed allocated mapping. Using DMA alone DT has to
> provide channel number. In router mode this number doesn't matter since router
> makes the routing from fixed event to channel. However router needs to know
> which channel will be assign to event: any random channel is allowed.

In dra7 both eDMA and sDMA have pre-allocated channel mapping. Before my
DMA event router support we had no way to use non default mapped events
(we did had DMA support fro HSMMC and probably other stuff with direct
DMA node).
When I had the DMA router, first I added the node for it, then I have
converted all existing nodes to use the DMA event router node for the
DMA binding. After that I could add the nodes for the peripherals
needing non default mapped DMA requests.
We don't allow direct DMA binding for dra7 class of devices at all,
everything needs to go via the xbars.

I would not bother with mixed use case here, I would just make it
mandatory to go via the router.

Again, with the eDMA I needed to 'mask' out the events/channels which we
want to use for memcpy. Define the memcpy channels in the eDMA node and
mask the same events in the crossbar as well.

> I'm pretty sure I can mimic what has been for DRA7 related to DMA Channel
> allocation however it seems to be this is aside DMA engine. This kind of
> implementation forbid the use of DMA and DMA router at the same time : I
> remember you already raise the point. If a DMA channel is requested DMA router
> is not aware of this allocation. This is the idea of my custom API which relies
> on get_any_slave_channel().

I think you must not allow mixed use for the slave channels. The none
slave (memcpy) is still a pain, but you have managed it somehow in the past.

> Using DT to assign channel seems not a good idea either as I lost router's benefice.
> 
> BTW I need the channel ID within router.

Your use case is pretty close to the dra7 one we have.

> Looking at core or of_dma_router_xlate() I don't really know how to do it a
> generic manner.

You construct the dmaspec for the DMA, which will include the channel
number you have mapped the event to. If the DMA driver needs the channel
number _and_ the event number then both, but based on your description
your DMA engine itself is close to the eDMA of ours than the sDMA.

- Péter

Powered by blists - more mailing lists