From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752676AbdHBO3e (ORCPT ); Wed, 2 Aug 2017 10:29:34 -0400 Received: from mx07-00178001.pphosted.com ([62.209.51.94]:28235 "EHLO mx07-00178001.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751067AbdHBO3b (ORCPT ); Wed, 2 Aug 2017 10:29:31 -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> From: Pierre Yves MORDRET Message-ID: <0e16a519-3d60-f683-5517-12a520e0e521@st.com> Date: Wed, 2 Aug 2017 16:28:40 +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: <47ceba83-1097-072e-bed6-d1964bce7a25@ti.com> 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-02_07:,, signatures=0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08/02/2017 04:09 PM, Peter Ujfalusi wrote: > > Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki > > On 2017-08-02 16:11, Pierre Yves MORDRET wrote: >> Our SoC works with or without DMAMUX. Both binding is allowed. Using only DMA a >> ChannelId and request line is part of the binding. > > In our case the am335x's eDMA can work with or without the router, we > only use the router node if we need none default event for a given DMA > request line. > >> 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. > > I see, this is not much different then what we face with our dra7 > devices. In theory we could use direct DMA binding to the DMA controller > itself, but some requests would not be reachable, so we always use the > router's node for DMA on dra7 family. > > Basically the router would manage the ChannelID and create > 'st,stm32-dma' compatible dma_spec (the four parameters). > Afaik you could have 3 parameters for the router and create a four > parameter dma_spec, where the ChannelID is dynamically allocated. 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... > But you need to convert all peripherals to use the router's node for the > DMA. > > - 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: Wed, 2 Aug 2017 16:28:40 +0200 Message-ID: <0e16a519-3d60-f683-5517-12a520e0e521@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> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <47ceba83-1097-072e-bed6-d1964bce7a25@ti.com> 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 CgpPbiAwOC8wMi8yMDE3IDA0OjA5IFBNLCBQZXRlciBVamZhbHVzaSB3cm90ZToKPiAKPiBUZXhh cyBJbnN0cnVtZW50cyBGaW5sYW5kIE95LCBQb3Jra2FsYW5rYXR1IDIyLCAwMDE4MCBIZWxzaW5r aS4gWS10dW5udXMvQnVzaW5lc3MgSUQ6IDA2MTU1MjEtNC4gS290aXBhaWtrYS9Eb21pY2lsZTog SGVsc2lua2kKPiAKPiBPbiAyMDE3LTA4LTAyIDE2OjExLCBQaWVycmUgWXZlcyBNT1JEUkVUIHdy b3RlOgo+PiBPdXIgU29DIHdvcmtzIHdpdGggb3Igd2l0aG91dCBETUFNVVguIEJvdGggYmluZGlu ZyBpcyBhbGxvd2VkLiBVc2luZyBvbmx5IERNQSBhCj4+IENoYW5uZWxJZCBhbmQgcmVxdWVzdCBs aW5lIGlzIHBhcnQgb2YgdGhlIGJpbmRpbmcuCj4gCj4gSW4gb3VyIGNhc2UgdGhlIGFtMzM1eCdz IGVETUEgY2FuIHdvcmsgd2l0aCBvciB3aXRob3V0IHRoZSByb3V0ZXIsIHdlIAo+IG9ubHkgdXNl IHRoZSByb3V0ZXIgbm9kZSBpZiB3ZSBuZWVkIG5vbmUgZGVmYXVsdCBldmVudCBmb3IgYSBnaXZl biBETUEgCj4gcmVxdWVzdCBsaW5lLgo+IAo+PiBVc2luZyBETUFNVXggbm93IHRoZSByZXF1ZXN0 Cj4+IGxpbmUgaXMgY29taW5nIGZyb20gZG1hX3NwZWMgZm9yd2FyZHMgdG8gZG1hLW1hc3RlciBh cyB3ZWxsIGV4cGxhaW5lZCBieSBQZXRlci4KPj4gSG93ZXZlciBDaGFubmVsSUQgaXMgbm93IGdp dmVuIGJ5IGRtYV9nZXRfYW55X3NsYXZlX2NoYW5uZWwgaW5zdGVhZCBvZiBiaW5kaW5ncy4KPj4g RE1BTVVYIGRyaXZlciBoYXMgdG8gYmUgYXdhcmUgb2YgdGhpcyBJRCB0byByb3V0ZSByZXF1ZXN0 IGxpbmUgdG8gb3V0IERNQQo+PiBjaGFubmVsLiBUaGlzIGNoYW5uZWwgaWQgaW5mb3JtYXRpb24g aXMgY2FycmllZCBvbiB1bnRpbCBETUFNVVggdGhyb3VnaAo+PiBkbWFlbmdpbmVfc2xhdmVfY29u ZmlnIHdpdGggYSBjdXN0b20gQVBJLgo+PiBIb3BlIGl0IGNsYXJpZmllcyB0aGUgbmVlZC4KPiAK PiBJIHNlZSwgdGhpcyBpcyBub3QgbXVjaCBkaWZmZXJlbnQgdGhlbiB3aGF0IHdlIGZhY2Ugd2l0 aCBvdXIgZHJhNyAKPiBkZXZpY2VzLiBJbiB0aGVvcnkgd2UgY291bGQgdXNlIGRpcmVjdCBETUEg YmluZGluZyB0byB0aGUgRE1BIGNvbnRyb2xsZXIgCj4gaXRzZWxmLCBidXQgc29tZSByZXF1ZXN0 cyB3b3VsZCBub3QgYmUgcmVhY2hhYmxlLCBzbyB3ZSBhbHdheXMgdXNlIHRoZSAKPiByb3V0ZXIn cyBub2RlIGZvciBETUEgb24gZHJhNyBmYW1pbHkuCj4gCj4gQmFzaWNhbGx5IHRoZSByb3V0ZXIg d291bGQgbWFuYWdlIHRoZSBDaGFubmVsSUQgYW5kIGNyZWF0ZSAKPiAnc3Qsc3RtMzItZG1hJyBj b21wYXRpYmxlIGRtYV9zcGVjICh0aGUgZm91ciBwYXJhbWV0ZXJzKS4KPiBBZmFpayB5b3UgY291 bGQgaGF2ZSAzIHBhcmFtZXRlcnMgZm9yIHRoZSByb3V0ZXIgYW5kIGNyZWF0ZSBhIGZvdXIgCj4g cGFyYW1ldGVyIGRtYV9zcGVjLCB3aGVyZSB0aGUgQ2hhbm5lbElEIGlzIGR5bmFtaWNhbGx5IGFs bG9jYXRlZC4KCkNvcnJlY3Qgcm91dGVyIG5lZWRzIDMgcGFyYW1ldGVycyBhbmQgYW1vbmcgdGhv c2UgMiBhcmUgZm9yd2FyZGVkIHRob3VnaCBvdXQKZG1hX3NwZWMuIEJ1dCB3aGVuIHlvdSBzYXkg IkNoYW5uZWxJRCBpcyBkeW5hbWljYWxseSBhbGxvY2F0ZWQiIHlvdSBtZWFuCmRtYV9nZXRfYW55 X3NsYXZlX2NoYW5uZWwgPyBJZiB5ZXMgSSBjYW4gdXNlIHRoZSBhbHJlYWR5IGV4aXN0aW5nIGJp bmRpbmdzIHRvCmNhcnJ5IHRoZSBjaGFubmVsSUQgdG8gRE1BLiBObyBjaGFuZ2VzIG5lZWQgdG8g cGVyaXBoZXJhbC4uLgoKPiBCdXQgeW91IG5lZWQgdG8gY29udmVydCBhbGwgcGVyaXBoZXJhbHMg dG8gdXNlIHRoZSByb3V0ZXIncyBub2RlIGZvciB0aGUgCj4gRE1BLgo+IAo+IC0gUMOpdGVyCj4g CgpQeQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGlu dXgtYXJtLWtlcm5lbCBtYWlsaW5nIGxpc3QKbGludXgtYXJtLWtlcm5lbEBsaXN0cy5pbmZyYWRl YWQub3JnCmh0dHA6Ly9saXN0cy5pbmZyYWRlYWQub3JnL21haWxtYW4vbGlzdGluZm8vbGludXgt YXJtLWtlcm5lbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 From: pierre-yves.mordret@st.com (Pierre Yves MORDRET) Date: Wed, 2 Aug 2017 16:28:40 +0200 Subject: [PATCH v3 2/5] dmaengine: Add STM32 DMAMUX driver In-Reply-To: <47ceba83-1097-072e-bed6-d1964bce7a25@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> <7bcad698-fa1a-3dc2-e918-4400639ca6d7@st.com> <47ceba83-1097-072e-bed6-d1964bce7a25@ti.com> Message-ID: <0e16a519-3d60-f683-5517-12a520e0e521@st.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 08/02/2017 04:09 PM, Peter Ujfalusi wrote: > > Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki > > On 2017-08-02 16:11, Pierre Yves MORDRET wrote: >> Our SoC works with or without DMAMUX. Both binding is allowed. Using only DMA a >> ChannelId and request line is part of the binding. > > In our case the am335x's eDMA can work with or without the router, we > only use the router node if we need none default event for a given DMA > request line. > >> 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. > > I see, this is not much different then what we face with our dra7 > devices. In theory we could use direct DMA binding to the DMA controller > itself, but some requests would not be reachable, so we always use the > router's node for DMA on dra7 family. > > Basically the router would manage the ChannelID and create > 'st,stm32-dma' compatible dma_spec (the four parameters). > Afaik you could have 3 parameters for the router and create a four > parameter dma_spec, where the ChannelID is dynamically allocated. 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... > But you need to convert all peripherals to use the router's node for the > DMA. > > - P?ter > Py