From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751866AbdHCJBv (ORCPT ); Thu, 3 Aug 2017 05:01:51 -0400 Received: from mx08-00178001.pphosted.com ([91.207.212.93]:38947 "EHLO mx07-00178001.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751211AbdHCJBr (ORCPT ); Thu, 3 Aug 2017 05:01:47 -0400 Subject: Re: [PATCH v3 2/5] dmaengine: Add STM32 DMAMUX driver 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" 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> <7bcad698-fa1a-3dc2-e918-4400639ca6d7@st.com> <47ceba83-1097-072e-bed6-d1964bce7a25@ti.com> <0e16a519-3d60-f683-5517-12a520e0e521@st.com> From: Pierre Yves MORDRET Message-ID: <71b7ef2a-d745-d16b-4538-567c856cce9a@st.com> Date: Thu, 3 Aug 2017 11:00:55 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [10.75.127.45] X-ClientProxiedBy: SFHDAG7NODE3.st.com (10.75.127.21) To SFHDAG5NODE2.st.com (10.75.127.14) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-08-03_05:,, signatures=0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08/03/2017 08:42 AM, Peter Ujfalusi wrote: > our mail server started to mangle outgoing mails, sorry for that, we are > trying to resolve that... No problem ;) > > > Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki > > On 2017-08-02 17:28, Pierre Yves MORDRET wrote: >> Correct router needs 3 parameters and among those 2 are forwarded though out >> dma_spec. But when you say "ChannelID is dynamically allocated" you mean >> dma_get_any_slave_channel ? If yes I can use the already existing bindings to >> carry the channelID to DMA. No changes need to peripheral... > > What I actually mean is that you should not need to modify the DMA > driver at all. > According to stm32-dma.txt: > #dma-cells = <4>; > 1. channelID > 2. request line number > 3. - 4. some parameters > > I believe if you don't have the event router (directly using the DMA > node) you always need to provide these, right? Correct > If I'm not mistaken, when you use the event router you want to omit the > ChannelID and get a random channel via dma_get_any_slave_channel in the > DMA driver and feed back the channelID to the event router driver? Again correct. > I believe the reason for this is that you want to keep mixed binding > use, to have direct DMA bindings and bindings via event router. > Well no. peripheral has to use DMAMUX and mixing up is to be avoided. This is more for backward compatibility with SoC which doesn't have a DMAMUX. > Now what happens if you have direct binding: > device1 { > dmas = <&dma2 1 4 0x10400 0x3>; > }; > > and via event router: > device2 { > dmas = <&dma_router 10 0x10400 0x3>, > <&dma_router 11 0x10400 0x3>; > }; > > device2 probes first, will get channelID 0 and 1 via > dma_get_any_slave_channel. > > When device1 tries to probe, the channelID 1 is already taken.. Yes this is a flaw if we mix up bindings. > > You need to convert all peripherals to use the event router to avoid > such a races. I have done the same for the dra7. > Add the event router driver, > add the event router node and convert existing users to use that > when adding new devices, use the event router node. > > The event router's binding would have 3 parameters, it manages the > available channelIDs, like the ti-dma-crossbar does for dra7. At > allocate time it would pick an unused channelID and craft the dma-spec > with the four parameters as documented. > The main DMA driver will not need any modification as everything will be > taken care of by the event router. > I look up what has been done in ti-dma-crossbar and actually this DMAMUX driver has been well inspired from ti-dma-crossbar. Nonetheless I understand what you meant. The channelID doesn't come from the dmaengine and a piece a code is devised to allocate those. I could copy/paste such code in my side but I do believe this would be better if such information would come from dmaengine instead : this is what I did but a link/callback is missing to craft this info until DMA. ChannelID is computed in two places in dmaemgine and in your driver. Moreover any router is going to develop its own channelID allocator, info which normally comes from dmaengine. Vinod, I can update my driver to mimic what ti-dma-crossbar did to avoid the custom API. This is s rather big change to evaluate in my side though. However it seems to me such info should have come from dmaengine and not from driver. Let me know your thought about this > The only gotcha is with memcpy type of transfers as they might also need > unique channelID, but not requested via the slave binding. For that I > have added properties to the event router to mask out certain channels > (and I needed to do the same for the eDMA, but it is unrelated to the > router itself). > > > - Péter > Py 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: Thu, 3 Aug 2017 11:00:55 +0200 Message-ID: <71b7ef2a-d745-d16b-4538-567c856cce9a@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> <7bcad698-fa1a-3dc2-e918-4400639ca6d7@st.com> <47ceba83-1097-072e-bed6-d1964bce7a25@ti.com> <0e16a519-3d60-f683-5517-12a520e0e521@st.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Peter Ujfalusi , Vinod Koul Cc: Mark Rutland , "devicetree@vger.kernel.org" , Amelie DELAUNAY , Alexandre TORGUE , Russell King , Fabien DESSENNE , "linux-kernel@vger.kernel.org" , "dmaengine@vger.kernel.org" , Rob Herring , Maxime Coquelin , M'boumba Cedric Madianga , Dan Williams , Fabrice GASNIER , "linux-arm-kernel@lists.infradead.org" , Herbert Xu List-Id: devicetree@vger.kernel.org CgpPbiAwOC8wMy8yMDE3IDA4OjQyIEFNLCBQZXRlciBVamZhbHVzaSB3cm90ZToKPiBvdXIgbWFp bCBzZXJ2ZXIgc3RhcnRlZCB0byBtYW5nbGUgb3V0Z29pbmcgbWFpbHMsIHNvcnJ5IGZvciB0aGF0 LCB3ZSBhcmUgCj4gdHJ5aW5nIHRvIHJlc29sdmUgdGhhdC4uLgoKTm8gcHJvYmxlbSA7KQoKPiAK PiAKPiBUZXhhcyBJbnN0cnVtZW50cyBGaW5sYW5kIE95LCBQb3Jra2FsYW5rYXR1IDIyLCAwMDE4 MCBIZWxzaW5raS4gWS10dW5udXMvQnVzaW5lc3MgSUQ6IDA2MTU1MjEtNC4gS290aXBhaWtrYS9E b21pY2lsZTogSGVsc2lua2kKPiAKPiBPbiAyMDE3LTA4LTAyIDE3OjI4LCBQaWVycmUgWXZlcyBN T1JEUkVUIHdyb3RlOgo+PiBDb3JyZWN0IHJvdXRlciBuZWVkcyAzIHBhcmFtZXRlcnMgYW5kIGFt b25nIHRob3NlIDIgYXJlIGZvcndhcmRlZCB0aG91Z2ggb3V0Cj4+IGRtYV9zcGVjLiBCdXQgd2hl biB5b3Ugc2F5ICJDaGFubmVsSUQgaXMgZHluYW1pY2FsbHkgYWxsb2NhdGVkIiB5b3UgbWVhbgo+ PiBkbWFfZ2V0X2FueV9zbGF2ZV9jaGFubmVsID8gSWYgeWVzIEkgY2FuIHVzZSB0aGUgYWxyZWFk eSBleGlzdGluZyBiaW5kaW5ncyB0bwo+PiBjYXJyeSB0aGUgY2hhbm5lbElEIHRvIERNQS4gTm8g Y2hhbmdlcyBuZWVkIHRvIHBlcmlwaGVyYWwuLi4KPiAKPiBXaGF0IEkgYWN0dWFsbHkgbWVhbiBp cyB0aGF0IHlvdSBzaG91bGQgbm90IG5lZWQgdG8gbW9kaWZ5IHRoZSBETUEgCj4gZHJpdmVyIGF0 IGFsbC4KPiBBY2NvcmRpbmcgdG8gc3RtMzItZG1hLnR4dDoKPiAjZG1hLWNlbGxzID0gPDQ+Owo+ IDEuIGNoYW5uZWxJRAo+IDIuIHJlcXVlc3QgbGluZSBudW1iZXIKPiAzLiAtIDQuIHNvbWUgcGFy YW1ldGVycwo+IAo+IEkgYmVsaWV2ZSBpZiB5b3UgZG9uJ3QgaGF2ZSB0aGUgZXZlbnQgcm91dGVy IChkaXJlY3RseSB1c2luZyB0aGUgRE1BIAo+IG5vZGUpIHlvdSBhbHdheXMgbmVlZCB0byBwcm92 aWRlIHRoZXNlLCByaWdodD8KCkNvcnJlY3QKCj4gSWYgSSdtIG5vdCBtaXN0YWtlbiwgd2hlbiB5 b3UgdXNlIHRoZSBldmVudCByb3V0ZXIgeW91IHdhbnQgdG8gb21pdCB0aGUgCj4gQ2hhbm5lbElE IGFuZCBnZXQgYSByYW5kb20gY2hhbm5lbCB2aWEgZG1hX2dldF9hbnlfc2xhdmVfY2hhbm5lbCBp biB0aGUgCj4gRE1BIGRyaXZlciBhbmQgZmVlZCBiYWNrIHRoZSBjaGFubmVsSUQgdG8gdGhlIGV2 ZW50IHJvdXRlciBkcml2ZXI/CgpBZ2FpbiBjb3JyZWN0LgoKPiBJIGJlbGlldmUgdGhlIHJlYXNv biBmb3IgdGhpcyBpcyB0aGF0IHlvdSB3YW50IHRvIGtlZXAgbWl4ZWQgYmluZGluZyAKPiB1c2Us IHRvIGhhdmUgZGlyZWN0IERNQSBiaW5kaW5ncyBhbmQgYmluZGluZ3MgdmlhIGV2ZW50IHJvdXRl ci4KPiAKCldlbGwgbm8uIHBlcmlwaGVyYWwgaGFzIHRvIHVzZSBETUFNVVggYW5kIG1peGluZyB1 cCBpcyB0byBiZSBhdm9pZGVkLiBUaGlzIGlzCm1vcmUgZm9yIGJhY2t3YXJkIGNvbXBhdGliaWxp dHkgd2l0aCBTb0Mgd2hpY2ggZG9lc24ndCBoYXZlIGEgRE1BTVVYLgoKPiBOb3cgd2hhdCBoYXBw ZW5zIGlmIHlvdSBoYXZlIGRpcmVjdCBiaW5kaW5nOgo+IGRldmljZTEgewo+IAlkbWFzID0gPCZk bWEyIDEgNCAweDEwNDAwIDB4Mz47Cj4gfTsKPiAKPiBhbmQgdmlhIGV2ZW50IHJvdXRlcjoKPiBk ZXZpY2UyIHsKPiAJZG1hcyA9CTwmZG1hX3JvdXRlciAxMCAweDEwNDAwIDB4Mz4sCj4gCQk8JmRt YV9yb3V0ZXIgMTEgMHgxMDQwMCAweDM+Owo+IH07Cj4gCj4gZGV2aWNlMiBwcm9iZXMgZmlyc3Qs IHdpbGwgZ2V0IGNoYW5uZWxJRCAwIGFuZCAxIHZpYSAKPiBkbWFfZ2V0X2FueV9zbGF2ZV9jaGFu bmVsLgo+IAo+IFdoZW4gZGV2aWNlMSB0cmllcyB0byBwcm9iZSwgdGhlIGNoYW5uZWxJRCAxIGlz IGFscmVhZHkgdGFrZW4uLgoKWWVzIHRoaXMgaXMgYSBmbGF3IGlmIHdlIG1peCB1cCBiaW5kaW5n cy4KCj4gCj4gWW91IG5lZWQgdG8gY29udmVydCBhbGwgcGVyaXBoZXJhbHMgdG8gdXNlIHRoZSBl dmVudCByb3V0ZXIgdG8gYXZvaWQgCj4gc3VjaCBhIHJhY2VzLiBJIGhhdmUgZG9uZSB0aGUgc2Ft ZSBmb3IgdGhlIGRyYTcuCj4gQWRkIHRoZSBldmVudCByb3V0ZXIgZHJpdmVyLAo+IGFkZCB0aGUg ZXZlbnQgcm91dGVyIG5vZGUgYW5kIGNvbnZlcnQgZXhpc3RpbmcgdXNlcnMgdG8gdXNlIHRoYXQK PiB3aGVuIGFkZGluZyBuZXcgZGV2aWNlcywgdXNlIHRoZSBldmVudCByb3V0ZXIgbm9kZS4KPiAK PiBUaGUgZXZlbnQgcm91dGVyJ3MgYmluZGluZyB3b3VsZCBoYXZlIDMgcGFyYW1ldGVycywgaXQg bWFuYWdlcyB0aGUgCj4gYXZhaWxhYmxlIGNoYW5uZWxJRHMsIGxpa2UgdGhlIHRpLWRtYS1jcm9z c2JhciBkb2VzIGZvciBkcmE3LiBBdCAKPiBhbGxvY2F0ZSB0aW1lIGl0IHdvdWxkIHBpY2sgYW4g dW51c2VkIGNoYW5uZWxJRCBhbmQgY3JhZnQgdGhlIGRtYS1zcGVjIAo+IHdpdGggdGhlIGZvdXIg cGFyYW1ldGVycyBhcyBkb2N1bWVudGVkLgo+IFRoZSBtYWluIERNQSBkcml2ZXIgd2lsbCBub3Qg bmVlZCBhbnkgbW9kaWZpY2F0aW9uIGFzIGV2ZXJ5dGhpbmcgd2lsbCBiZSAKPiB0YWtlbiBjYXJl IG9mIGJ5IHRoZSBldmVudCByb3V0ZXIuCj4gCgpJIGxvb2sgdXAgd2hhdCBoYXMgYmVlbiBkb25l IGluIHRpLWRtYS1jcm9zc2JhciBhbmQgYWN0dWFsbHkgdGhpcyBETUFNVVggZHJpdmVyCmhhcyBi ZWVuIHdlbGwgaW5zcGlyZWQgZnJvbSB0aS1kbWEtY3Jvc3NiYXIuCk5vbmV0aGVsZXNzIEkgdW5k ZXJzdGFuZCB3aGF0IHlvdSBtZWFudC4gVGhlIGNoYW5uZWxJRCBkb2Vzbid0IGNvbWUgZnJvbSB0 aGUKZG1hZW5naW5lIGFuZCBhIHBpZWNlIGEgY29kZSBpcyBkZXZpc2VkIHRvIGFsbG9jYXRlIHRo b3NlLiBJIGNvdWxkIGNvcHkvcGFzdGUKc3VjaCBjb2RlIGluIG15IHNpZGUgYnV0IEkgZG8gYmVs aWV2ZSB0aGlzIHdvdWxkIGJlIGJldHRlciBpZiBzdWNoIGluZm9ybWF0aW9uCndvdWxkIGNvbWUg ZnJvbSBkbWFlbmdpbmUgaW5zdGVhZCA6IHRoaXMgaXMgd2hhdCBJIGRpZCBidXQgYSBsaW5rL2Nh bGxiYWNrIGlzCm1pc3NpbmcgdG8gY3JhZnQgdGhpcyBpbmZvIHVudGlsIERNQS4gQ2hhbm5lbElE IGlzIGNvbXB1dGVkIGluIHR3byBwbGFjZXMgaW4KZG1hZW1naW5lIGFuZCBpbiB5b3VyIGRyaXZl ci4gTW9yZW92ZXIgYW55IHJvdXRlciBpcyBnb2luZyB0byBkZXZlbG9wIGl0cyBvd24KY2hhbm5l bElEIGFsbG9jYXRvciwgaW5mbyB3aGljaCBub3JtYWxseSBjb21lcyBmcm9tIGRtYWVuZ2luZS4K ClZpbm9kLCBJIGNhbiB1cGRhdGUgbXkgZHJpdmVyIHRvIG1pbWljIHdoYXQgdGktZG1hLWNyb3Nz YmFyIGRpZCB0byBhdm9pZCB0aGUKY3VzdG9tIEFQSS4gVGhpcyBpcyBzIHJhdGhlciBiaWcgY2hh bmdlIHRvIGV2YWx1YXRlIGluIG15IHNpZGUgdGhvdWdoLgpIb3dldmVyIGl0IHNlZW1zIHRvIG1l IHN1Y2ggaW5mbyBzaG91bGQgaGF2ZSBjb21lIGZyb20gZG1hZW5naW5lIGFuZCBub3QgZnJvbQpk cml2ZXIuCkxldCBtZSBrbm93IHlvdXIgdGhvdWdodCBhYm91dCB0aGlzCgo+IFRoZSBvbmx5IGdv dGNoYSBpcyB3aXRoIG1lbWNweSB0eXBlIG9mIHRyYW5zZmVycyBhcyB0aGV5IG1pZ2h0IGFsc28g bmVlZCAKPiB1bmlxdWUgY2hhbm5lbElELCBidXQgbm90IHJlcXVlc3RlZCB2aWEgdGhlIHNsYXZl IGJpbmRpbmcuIEZvciB0aGF0IEkgCj4gaGF2ZSBhZGRlZCBwcm9wZXJ0aWVzIHRvIHRoZSBldmVu dCByb3V0ZXIgdG8gbWFzayBvdXQgY2VydGFpbiBjaGFubmVscyAKPiAoYW5kIEkgbmVlZGVkIHRv IGRvIHRoZSBzYW1lIGZvciB0aGUgZURNQSwgYnV0IGl0IGlzIHVucmVsYXRlZCB0byB0aGUgCj4g cm91dGVyIGl0c2VsZikuCj4gCj4gCj4gLSBQw6l0ZXIKPiAKClB5CgpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpsaW51eC1hcm0ta2VybmVsIG1haWxpbmcg bGlzdApsaW51eC1hcm0ta2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmcKaHR0cDovL2xpc3RzLmlu ZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1hcm0ta2VybmVsCg== From mboxrd@z Thu Jan 1 00:00:00 1970 From: pierre-yves.mordret@st.com (Pierre Yves MORDRET) Date: Thu, 3 Aug 2017 11:00:55 +0200 Subject: [PATCH v3 2/5] dmaengine: Add STM32 DMAMUX driver In-Reply-To: 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> <7bcad698-fa1a-3dc2-e918-4400639ca6d7@st.com> <47ceba83-1097-072e-bed6-d1964bce7a25@ti.com> <0e16a519-3d60-f683-5517-12a520e0e521@st.com> Message-ID: <71b7ef2a-d745-d16b-4538-567c856cce9a@st.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 08/03/2017 08:42 AM, Peter Ujfalusi wrote: > our mail server started to mangle outgoing mails, sorry for that, we are > trying to resolve that... No problem ;) > > > Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki > > On 2017-08-02 17:28, Pierre Yves MORDRET wrote: >> Correct router needs 3 parameters and among those 2 are forwarded though out >> dma_spec. But when you say "ChannelID is dynamically allocated" you mean >> dma_get_any_slave_channel ? If yes I can use the already existing bindings to >> carry the channelID to DMA. No changes need to peripheral... > > What I actually mean is that you should not need to modify the DMA > driver at all. > According to stm32-dma.txt: > #dma-cells = <4>; > 1. channelID > 2. request line number > 3. - 4. some parameters > > I believe if you don't have the event router (directly using the DMA > node) you always need to provide these, right? Correct > If I'm not mistaken, when you use the event router you want to omit the > ChannelID and get a random channel via dma_get_any_slave_channel in the > DMA driver and feed back the channelID to the event router driver? Again correct. > I believe the reason for this is that you want to keep mixed binding > use, to have direct DMA bindings and bindings via event router. > Well no. peripheral has to use DMAMUX and mixing up is to be avoided. This is more for backward compatibility with SoC which doesn't have a DMAMUX. > Now what happens if you have direct binding: > device1 { > dmas = <&dma2 1 4 0x10400 0x3>; > }; > > and via event router: > device2 { > dmas = <&dma_router 10 0x10400 0x3>, > <&dma_router 11 0x10400 0x3>; > }; > > device2 probes first, will get channelID 0 and 1 via > dma_get_any_slave_channel. > > When device1 tries to probe, the channelID 1 is already taken.. Yes this is a flaw if we mix up bindings. > > You need to convert all peripherals to use the event router to avoid > such a races. I have done the same for the dra7. > Add the event router driver, > add the event router node and convert existing users to use that > when adding new devices, use the event router node. > > The event router's binding would have 3 parameters, it manages the > available channelIDs, like the ti-dma-crossbar does for dra7. At > allocate time it would pick an unused channelID and craft the dma-spec > with the four parameters as documented. > The main DMA driver will not need any modification as everything will be > taken care of by the event router. > I look up what has been done in ti-dma-crossbar and actually this DMAMUX driver has been well inspired from ti-dma-crossbar. Nonetheless I understand what you meant. The channelID doesn't come from the dmaengine and a piece a code is devised to allocate those. I could copy/paste such code in my side but I do believe this would be better if such information would come from dmaengine instead : this is what I did but a link/callback is missing to craft this info until DMA. ChannelID is computed in two places in dmaemgine and in your driver. Moreover any router is going to develop its own channelID allocator, info which normally comes from dmaengine. Vinod, I can update my driver to mimic what ti-dma-crossbar did to avoid the custom API. This is s rather big change to evaluate in my side though. However it seems to me such info should have come from dmaengine and not from driver. Let me know your thought about this > The only gotcha is with memcpy type of transfers as they might also need > unique channelID, but not requested via the slave binding. For that I > have added properties to the event router to mask out certain channels > (and I needed to do the same for the eDMA, but it is unrelated to the > router itself). > > > - P?ter > Py