From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752078AbdHBNMr (ORCPT ); Wed, 2 Aug 2017 09:12:47 -0400 Received: from mx07-00178001.pphosted.com ([62.209.51.94]:52850 "EHLO mx07-00178001.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751197AbdHBNMo (ORCPT ); Wed, 2 Aug 2017 09:12:44 -0400 From: Pierre Yves MORDRET To: Peter Ujfalusi , Vinod Koul CC: Rob Herring , Mark Rutland , Maxime Coquelin , Alexandre TORGUE , Russell King , Dan Williams , "M'boumba Cedric Madianga" , Fabrice GASNIER , Herbert Xu , Fabien DESSENNE , Amelie DELAUNAY , "dmaengine@vger.kernel.org" , "devicetree@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH v3 2/5] dmaengine: Add STM32 DMAMUX driver Thread-Topic: [PATCH v3 2/5] dmaengine: Add STM32 DMAMUX driver Thread-Index: AQHS9lJEsWaINqWfUEGtL1SBd5FJmqJfX72AgAObA4CAApdkgIAAI+EAgAgtzoCAAWBKAIABRM8AgABJrwCAAED8gA== Date: Wed, 2 Aug 2017 13:11:41 +0000 Message-ID: <7bcad698-fa1a-3dc2-e918-4400639ca6d7@st.com> References: <1499343623-5964-1-git-send-email-pierre-yves.mordret@st.com> <1499343623-5964-3-git-send-email-pierre-yves.mordret@st.com> <20170722065133.GT3053@localhost> <2b916330-9b65-f4d5-817f-79b66cc236b3@st.com> <20170726052930.GF3053@localhost> <20170731123157.GJ3053@localhost> <20170802045522.GU3053@localhost> <7d2091fe-a2e5-78bb-b63d-9cb66bdb7e84@ti.com> In-Reply-To: <7d2091fe-a2e5-78bb-b63d-9cb66bdb7e84@ti.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.75.127.44] Content-Type: text/plain; charset="utf-8" Content-ID: MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-08-02_07:,, signatures=0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by nfs id v72DCqrn022413 On 08/02/2017 11:19 AM, Peter Ujfalusi wrote: > > > On 2017-08-02 07:55, Vinod Koul wrote: >> On Tue, Aug 01, 2017 at 09:32:50AM +0000, Pierre Yves MORDRET wrote: >>> >>> >>> On 07/31/2017 02:31 PM, Vinod Koul wrote: >>>> On Wed, Jul 26, 2017 at 07:38:02AM +0000, Pierre Yves MORDRET wrote: >>>>>>>>> + >>>>>>>>> +#ifndef __DMA_STM32_DMAMUX_H >>>>>>>>> +#define __DMA_STM32_DMAMUX_H >>>>>>>>> + >>>>>>>>> +#if defined(CONFIG_STM32_DMAMUX) >>>>>>>>> +int stm32_dmamux_set_config(struct device *dev, void *route_data, u32 chan_id); >>>>>>>> >>>>>>>> Why do we need a custom API in this case? >>>>>>>> >>>>>>> >>>>>>> This API is called by DMA when a slave is requested by client. DMA can work >>>>>>> without DMAMUX this API has been put in place to configure DMAMUX whether client >>>>>>> is requesting a DMAMUX Channel instead of a DMA one. >>>>>> >>>>>> You mean the dmaengine driver right? >>>>>> >>>>> >>>>> Yes. The API is mainly called by "device_config" through out STM32 DMA Driver >>>>> when a router is in place for client. >>>>> Please refer to Patch 4/5 on this set. >>>> >>>> Okay am thinking on why this can't be generic..? An optional router config >>>> callback? >>>> >>> >>> I would have liked to answer there is a callback within engine but unfortunately >>> I didn't figure out one when I did my router's development. I've looked once >>> more but again I can't find how to map chanID and request line without custom API. >> >> Yes there is no callback for routers but we can add a generic callback >> here to be used. I added Peter for his comments, isn't that something they >> need too? > > The event router via of_dma_router_register() should be capable of > handling different type of muxers, like the ti-dma-crossbar.c is doing > for two different type of event crossbars. > > Basically with the of_dma_route_allocate you craft a dma_spec which can > be understood by the dma-master pointed form the router's node. > You do the configuration of the mux in this function, craft the dma_spec > and that's it. In DT the peripherals are using the router's node for DMA > binding and everything is transparent for them. > > Note: The use of am335x xbar in the ti-dma-crossbar is optional and only > needed when we need to have different event than the default for a > specific dma request line. > > If you normally use the DMA like this: > dmas = <&edma 129 1>, <&ddma_xbar 128 1>; > dma-names = "tx", "rx"; > > If you have DMA event router/mux, then depending on how it works you > might have different number of parameters. In my case the DRA7 crossbar > does not need extra parameter, so to get it in use: > dmas = <&edma_xbar 129 1>, <&edma_xbar 128 1>; > dma-names = "tx", "rx"; > > The router driver will rewrite the dma_spec and replace the 129/128 and > pass something different to the dma-master (dynamic event mapping). > > On am335x we have different xbar type so there: > > dmas = <&edma_xbar 12 0 1>, <&edma_xbar 13 0 2>; > > Out from this the router driver will create a spec equivalent to > dmas = <&edma_xbar 12 0>, <&edma_xbar 13 0>; > > But it will change the xbar that DMA request 12/13 will not have the > default event routed to. > > I believe that the dma_router infra we have in dmaengine can cover most > if not all use cases... > > - Péter > Our SoC works with or without DMAMUX. Both binding is allowed. Using only DMA a ChannelId and request line is part of the binding. Using DMAMUx now the request line is coming from dma_spec forwards to dma-master as well explained by Peter. However ChannelID is now given by dma_get_any_slave_channel instead of bindings. DMAMUX driver has to be aware of this ID to route request line to out DMA channel. This channel id information is carried on until DMAMUX through dmaengine_slave_config with a custom API. Hope it clarifies the need. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pierre Yves MORDRET Subject: Re: [PATCH v3 2/5] dmaengine: Add STM32 DMAMUX driver Date: Wed, 2 Aug 2017 13:11:41 +0000 Message-ID: <7bcad698-fa1a-3dc2-e918-4400639ca6d7@st.com> References: <1499343623-5964-1-git-send-email-pierre-yves.mordret@st.com> <1499343623-5964-3-git-send-email-pierre-yves.mordret@st.com> <20170722065133.GT3053@localhost> <2b916330-9b65-f4d5-817f-79b66cc236b3@st.com> <20170726052930.GF3053@localhost> <20170731123157.GJ3053@localhost> <20170802045522.GU3053@localhost> <7d2091fe-a2e5-78bb-b63d-9cb66bdb7e84@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <7d2091fe-a2e5-78bb-b63d-9cb66bdb7e84@ti.com> Content-Language: en-US Content-ID: Sender: linux-kernel-owner@vger.kernel.org To: Peter Ujfalusi , Vinod Koul Cc: Rob Herring , Mark Rutland , Maxime Coquelin , Alexandre TORGUE , Russell King , Dan Williams , M'boumba Cedric Madianga , Fabrice GASNIER , Herbert Xu , Fabien DESSENNE , Amelie DELAUNAY , "dmaengine@vger.kernel.org" , "devicetree@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" List-Id: devicetree@vger.kernel.org DQoNCk9uIDA4LzAyLzIwMTcgMTE6MTkgQU0sIFBldGVyIFVqZmFsdXNpIHdyb3RlOg0KPiANCj4g DQo+IE9uIDIwMTctMDgtMDIgMDc6NTUsIFZpbm9kIEtvdWwgd3JvdGU6DQo+PiBPbiBUdWUsIEF1 ZyAwMSwgMjAxNyBhdCAwOTozMjo1MEFNICswMDAwLCBQaWVycmUgWXZlcyBNT1JEUkVUIHdyb3Rl Og0KPj4+DQo+Pj4NCj4+PiBPbiAwNy8zMS8yMDE3IDAyOjMxIFBNLCBWaW5vZCBLb3VsIHdyb3Rl Og0KPj4+PiBPbiBXZWQsIEp1bCAyNiwgMjAxNyBhdCAwNzozODowMkFNICswMDAwLCBQaWVycmUg WXZlcyBNT1JEUkVUIHdyb3RlOg0KPj4+Pj4+Pj4+ICsNCj4+Pj4+Pj4+PiArI2lmbmRlZiBfX0RN QV9TVE0zMl9ETUFNVVhfSA0KPj4+Pj4+Pj4+ICsjZGVmaW5lIF9fRE1BX1NUTTMyX0RNQU1VWF9I DQo+Pj4+Pj4+Pj4gKw0KPj4+Pj4+Pj4+ICsjaWYgZGVmaW5lZChDT05GSUdfU1RNMzJfRE1BTVVY KQ0KPj4+Pj4+Pj4+ICtpbnQgc3RtMzJfZG1hbXV4X3NldF9jb25maWcoc3RydWN0IGRldmljZSAq ZGV2LCB2b2lkICpyb3V0ZV9kYXRhLCB1MzIgY2hhbl9pZCk7DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4g V2h5IGRvIHdlIG5lZWQgYSBjdXN0b20gQVBJIGluIHRoaXMgY2FzZT8NCj4+Pj4+Pj4+DQo+Pj4+ Pj4+DQo+Pj4+Pj4+IFRoaXMgQVBJIGlzIGNhbGxlZCBieSBETUEgd2hlbiBhIHNsYXZlIGlzIHJl cXVlc3RlZCBieSBjbGllbnQuIERNQSBjYW4gd29yaw0KPj4+Pj4+PiB3aXRob3V0IERNQU1VWCB0 aGlzIEFQSSBoYXMgYmVlbiBwdXQgaW4gcGxhY2UgdG8gY29uZmlndXJlIERNQU1VWCB3aGV0aGVy IGNsaWVudA0KPj4+Pj4+PiBpcyByZXF1ZXN0aW5nIGEgRE1BTVVYIENoYW5uZWwgaW5zdGVhZCBv ZiBhIERNQSBvbmUuDQo+Pj4+Pj4NCj4+Pj4+PiBZb3UgbWVhbiB0aGUgZG1hZW5naW5lIGRyaXZl ciByaWdodD8NCj4+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IFllcy4gVGhlIEFQSSBpcyBtYWlubHkgY2Fs bGVkIGJ5ICJkZXZpY2VfY29uZmlnIiB0aHJvdWdoIG91dCBTVE0zMiBETUEgRHJpdmVyDQo+Pj4+ PiB3aGVuIGEgcm91dGVyIGlzIGluIHBsYWNlIGZvciBjbGllbnQuDQo+Pj4+PiBQbGVhc2UgcmVm ZXIgdG8gUGF0Y2ggNC81IG9uIHRoaXMgc2V0Lg0KPj4+Pg0KPj4+PiBPa2F5IGFtIHRoaW5raW5n IG9uIHdoeSB0aGlzIGNhbid0IGJlIGdlbmVyaWMuLj8gQW4gb3B0aW9uYWwgcm91dGVyIGNvbmZp Zw0KPj4+PiBjYWxsYmFjaz8NCj4+Pj4NCj4+Pg0KPj4+IEkgd291bGQgaGF2ZSBsaWtlZCB0byBh bnN3ZXIgdGhlcmUgaXMgYSBjYWxsYmFjayB3aXRoaW4gZW5naW5lIGJ1dCB1bmZvcnR1bmF0ZWx5 DQo+Pj4gSSBkaWRuJ3QgZmlndXJlIG91dCBvbmUgd2hlbiBJIGRpZCBteSByb3V0ZXIncyBkZXZl bG9wbWVudC4gSSd2ZSBsb29rZWQgb25jZQ0KPj4+IG1vcmUgYnV0IGFnYWluIEkgY2FuJ3QgZmlu ZCBob3cgdG8gbWFwIGNoYW5JRCBhbmQgcmVxdWVzdCBsaW5lIHdpdGhvdXQgY3VzdG9tIEFQSS4N Cj4+DQo+PiBZZXMgdGhlcmUgaXMgbm8gY2FsbGJhY2sgZm9yIHJvdXRlcnMgYnV0IHdlIGNhbiBh ZGQgYSBnZW5lcmljIGNhbGxiYWNrDQo+PiBoZXJlIHRvIGJlIHVzZWQuIEkgYWRkZWQgUGV0ZXIg Zm9yIGhpcyBjb21tZW50cywgaXNuJ3QgdGhhdCBzb21ldGhpbmcgdGhleQ0KPj4gbmVlZCB0b28/ DQo+IA0KPiBUaGUgZXZlbnQgcm91dGVyIHZpYSBvZl9kbWFfcm91dGVyX3JlZ2lzdGVyKCkgc2hv dWxkIGJlIGNhcGFibGUgb2YgDQo+IGhhbmRsaW5nIGRpZmZlcmVudCB0eXBlIG9mIG11eGVycywg bGlrZSB0aGUgdGktZG1hLWNyb3NzYmFyLmMgaXMgZG9pbmcgDQo+IGZvciB0d28gZGlmZmVyZW50 IHR5cGUgb2YgZXZlbnQgY3Jvc3NiYXJzLg0KPiANCj4gQmFzaWNhbGx5IHdpdGggdGhlIG9mX2Rt YV9yb3V0ZV9hbGxvY2F0ZSB5b3UgY3JhZnQgYSBkbWFfc3BlYyB3aGljaCBjYW4gDQo+IGJlIHVu ZGVyc3Rvb2QgYnkgdGhlIGRtYS1tYXN0ZXIgcG9pbnRlZCBmb3JtIHRoZSByb3V0ZXIncyBub2Rl Lg0KPiBZb3UgZG8gdGhlIGNvbmZpZ3VyYXRpb24gb2YgdGhlIG11eCBpbiB0aGlzIGZ1bmN0aW9u LCBjcmFmdCB0aGUgZG1hX3NwZWMgDQo+IGFuZCB0aGF0J3MgaXQuIEluIERUIHRoZSBwZXJpcGhl cmFscyBhcmUgdXNpbmcgdGhlIHJvdXRlcidzIG5vZGUgZm9yIERNQSANCj4gYmluZGluZyBhbmQg ZXZlcnl0aGluZyBpcyB0cmFuc3BhcmVudCBmb3IgdGhlbS4NCj4gDQo+IE5vdGU6IFRoZSB1c2Ug b2YgYW0zMzV4IHhiYXIgaW4gdGhlIHRpLWRtYS1jcm9zc2JhciBpcyBvcHRpb25hbCBhbmQgb25s eSANCj4gbmVlZGVkIHdoZW4gd2UgbmVlZCB0byBoYXZlIGRpZmZlcmVudCBldmVudCB0aGFuIHRo ZSBkZWZhdWx0IGZvciBhIA0KPiBzcGVjaWZpYyBkbWEgcmVxdWVzdCBsaW5lLg0KPiANCj4gSWYg eW91IG5vcm1hbGx5IHVzZSB0aGUgRE1BIGxpa2UgdGhpczoNCj4gZG1hcyA9IDwmZWRtYSAxMjkg MT4sIDwmZGRtYV94YmFyIDEyOCAxPjsNCj4gZG1hLW5hbWVzID0gInR4IiwgInJ4IjsNCj4gDQo+ IElmIHlvdSBoYXZlIERNQSBldmVudCByb3V0ZXIvbXV4LCB0aGVuIGRlcGVuZGluZyBvbiBob3cg aXQgd29ya3MgeW91IA0KPiBtaWdodCBoYXZlIGRpZmZlcmVudCBudW1iZXIgb2YgcGFyYW1ldGVy cy4gSW4gbXkgY2FzZSB0aGUgRFJBNyBjcm9zc2JhciANCj4gZG9lcyBub3QgbmVlZCBleHRyYSBw YXJhbWV0ZXIsIHNvIHRvIGdldCBpdCBpbiB1c2U6DQo+IGRtYXMgPSA8JmVkbWFfeGJhciAxMjkg MT4sIDwmZWRtYV94YmFyIDEyOCAxPjsNCj4gZG1hLW5hbWVzID0gInR4IiwgInJ4IjsNCj4gDQo+ IFRoZSByb3V0ZXIgZHJpdmVyIHdpbGwgcmV3cml0ZSB0aGUgZG1hX3NwZWMgYW5kIHJlcGxhY2Ug dGhlIDEyOS8xMjggYW5kIA0KPiBwYXNzIHNvbWV0aGluZyBkaWZmZXJlbnQgdG8gdGhlIGRtYS1t YXN0ZXIgKGR5bmFtaWMgZXZlbnQgbWFwcGluZykuDQo+IA0KPiBPbiBhbTMzNXggd2UgaGF2ZSBk aWZmZXJlbnQgeGJhciB0eXBlIHNvIHRoZXJlOg0KPiANCj4gZG1hcyA9IDwmZWRtYV94YmFyIDEy IDAgMT4sIDwmZWRtYV94YmFyIDEzIDAgMj47DQo+IA0KPiBPdXQgZnJvbSB0aGlzIHRoZSByb3V0 ZXIgZHJpdmVyIHdpbGwgY3JlYXRlIGEgc3BlYyBlcXVpdmFsZW50IHRvDQo+IGRtYXMgPSA8JmVk bWFfeGJhciAxMiAwPiwgPCZlZG1hX3hiYXIgMTMgMD47DQo+IA0KPiBCdXQgaXQgd2lsbCBjaGFu Z2UgdGhlIHhiYXIgdGhhdCBETUEgcmVxdWVzdCAxMi8xMyB3aWxsIG5vdCBoYXZlIHRoZSANCj4g ZGVmYXVsdCBldmVudCByb3V0ZWQgdG8uDQo+IA0KPiBJIGJlbGlldmUgdGhhdCB0aGUgZG1hX3Jv dXRlciBpbmZyYSB3ZSBoYXZlIGluIGRtYWVuZ2luZSBjYW4gY292ZXIgbW9zdCANCj4gaWYgbm90 IGFsbCB1c2UgY2FzZXMuLi4NCj4gDQo+IC0gUMOpdGVyDQo+IA0KDQpPdXIgU29DIHdvcmtzIHdp dGggb3Igd2l0aG91dCBETUFNVVguIEJvdGggYmluZGluZyBpcyBhbGxvd2VkLiBVc2luZyBvbmx5 IERNQSBhDQpDaGFubmVsSWQgYW5kIHJlcXVlc3QgbGluZSBpcyBwYXJ0IG9mIHRoZSBiaW5kaW5n LiBVc2luZyBETUFNVXggbm93IHRoZSByZXF1ZXN0DQpsaW5lIGlzIGNvbWluZyBmcm9tIGRtYV9z cGVjIGZvcndhcmRzIHRvIGRtYS1tYXN0ZXIgYXMgd2VsbCBleHBsYWluZWQgYnkgUGV0ZXIuDQpI b3dldmVyIENoYW5uZWxJRCBpcyBub3cgZ2l2ZW4gYnkgZG1hX2dldF9hbnlfc2xhdmVfY2hhbm5l bCBpbnN0ZWFkIG9mIGJpbmRpbmdzLg0KRE1BTVVYIGRyaXZlciBoYXMgdG8gYmUgYXdhcmUgb2Yg dGhpcyBJRCB0byByb3V0ZSByZXF1ZXN0IGxpbmUgdG8gb3V0IERNQQ0KY2hhbm5lbC4gVGhpcyBj aGFubmVsIGlkIGluZm9ybWF0aW9uIGlzIGNhcnJpZWQgb24gdW50aWwgRE1BTVVYIHRocm91Z2gN CmRtYWVuZ2luZV9zbGF2ZV9jb25maWcgd2l0aCBhIGN1c3RvbSBBUEkuDQpIb3BlIGl0IGNsYXJp ZmllcyB0aGUgbmVlZC4NCg== From mboxrd@z Thu Jan 1 00:00:00 1970 From: pierre-yves.mordret@st.com (Pierre Yves MORDRET) Date: Wed, 2 Aug 2017 13:11:41 +0000 Subject: [PATCH v3 2/5] dmaengine: Add STM32 DMAMUX driver In-Reply-To: <7d2091fe-a2e5-78bb-b63d-9cb66bdb7e84@ti.com> References: <1499343623-5964-1-git-send-email-pierre-yves.mordret@st.com> <1499343623-5964-3-git-send-email-pierre-yves.mordret@st.com> <20170722065133.GT3053@localhost> <2b916330-9b65-f4d5-817f-79b66cc236b3@st.com> <20170726052930.GF3053@localhost> <20170731123157.GJ3053@localhost> <20170802045522.GU3053@localhost> <7d2091fe-a2e5-78bb-b63d-9cb66bdb7e84@ti.com> Message-ID: <7bcad698-fa1a-3dc2-e918-4400639ca6d7@st.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 08/02/2017 11:19 AM, Peter Ujfalusi wrote: > > > On 2017-08-02 07:55, Vinod Koul wrote: >> On Tue, Aug 01, 2017 at 09:32:50AM +0000, Pierre Yves MORDRET wrote: >>> >>> >>> On 07/31/2017 02:31 PM, Vinod Koul wrote: >>>> On Wed, Jul 26, 2017 at 07:38:02AM +0000, Pierre Yves MORDRET wrote: >>>>>>>>> + >>>>>>>>> +#ifndef __DMA_STM32_DMAMUX_H >>>>>>>>> +#define __DMA_STM32_DMAMUX_H >>>>>>>>> + >>>>>>>>> +#if defined(CONFIG_STM32_DMAMUX) >>>>>>>>> +int stm32_dmamux_set_config(struct device *dev, void *route_data, u32 chan_id); >>>>>>>> >>>>>>>> Why do we need a custom API in this case? >>>>>>>> >>>>>>> >>>>>>> This API is called by DMA when a slave is requested by client. DMA can work >>>>>>> without DMAMUX this API has been put in place to configure DMAMUX whether client >>>>>>> is requesting a DMAMUX Channel instead of a DMA one. >>>>>> >>>>>> You mean the dmaengine driver right? >>>>>> >>>>> >>>>> Yes. The API is mainly called by "device_config" through out STM32 DMA Driver >>>>> when a router is in place for client. >>>>> Please refer to Patch 4/5 on this set. >>>> >>>> Okay am thinking on why this can't be generic..? An optional router config >>>> callback? >>>> >>> >>> I would have liked to answer there is a callback within engine but unfortunately >>> I didn't figure out one when I did my router's development. I've looked once >>> more but again I can't find how to map chanID and request line without custom API. >> >> Yes there is no callback for routers but we can add a generic callback >> here to be used. I added Peter for his comments, isn't that something they >> need too? > > The event router via of_dma_router_register() should be capable of > handling different type of muxers, like the ti-dma-crossbar.c is doing > for two different type of event crossbars. > > Basically with the of_dma_route_allocate you craft a dma_spec which can > be understood by the dma-master pointed form the router's node. > You do the configuration of the mux in this function, craft the dma_spec > and that's it. In DT the peripherals are using the router's node for DMA > binding and everything is transparent for them. > > Note: The use of am335x xbar in the ti-dma-crossbar is optional and only > needed when we need to have different event than the default for a > specific dma request line. > > If you normally use the DMA like this: > dmas = <&edma 129 1>, <&ddma_xbar 128 1>; > dma-names = "tx", "rx"; > > If you have DMA event router/mux, then depending on how it works you > might have different number of parameters. In my case the DRA7 crossbar > does not need extra parameter, so to get it in use: > dmas = <&edma_xbar 129 1>, <&edma_xbar 128 1>; > dma-names = "tx", "rx"; > > The router driver will rewrite the dma_spec and replace the 129/128 and > pass something different to the dma-master (dynamic event mapping). > > On am335x we have different xbar type so there: > > dmas = <&edma_xbar 12 0 1>, <&edma_xbar 13 0 2>; > > Out from this the router driver will create a spec equivalent to > dmas = <&edma_xbar 12 0>, <&edma_xbar 13 0>; > > But it will change the xbar that DMA request 12/13 will not have the > default event routed to. > > I believe that the dma_router infra we have in dmaengine can cover most > if not all use cases... > > - P?ter > Our SoC works with or without DMAMUX. Both binding is allowed. Using only DMA a ChannelId and request line is part of the binding. Using DMAMUx now the request line is coming from dma_spec forwards to dma-master as well explained by Peter. However ChannelID is now given by dma_get_any_slave_channel instead of bindings. DMAMUX driver has to be aware of this ID to route request line to out DMA channel. This channel id information is carried on until DMAMUX through dmaengine_slave_config with a custom API. Hope it clarifies the need.