From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752097AbdHDOYu (ORCPT ); Fri, 4 Aug 2017 10:24:50 -0400 Received: from fllnx209.ext.ti.com ([198.47.19.16]:61879 "EHLO fllnx209.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751304AbdHDOYr (ORCPT ); Fri, 4 Aug 2017 10:24:47 -0400 Subject: Re: [PATCH v3 2/5] dmaengine: Add STM32 DMAMUX driver To: Pierre Yves MORDRET , 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> <71b7ef2a-d745-d16b-4538-567c856cce9a@st.com> <401305f0-15d8-1996-60d6-69c13cbacc06@ti.com> <58bf2f7c-faf1-d1e9-3c87-d7964d1ba3d4@st.com> From: Peter Ujfalusi Message-ID: <6e8e19f1-8d0f-183b-e02f-1ec8c4dd57b3@ti.com> Date: Fri, 4 Aug 2017 17:21:03 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <58bf2f7c-faf1-d1e9-3c87-d7964d1ba3d4@st.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-GB Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08/04/2017 03:50 PM, Pierre Yves MORDRET wrote: > Our DMAMUX can manage up to 255 request lines (only 128 is eventually assigned > though) onto 16 events: 8 events mapped on 1 DMA and the 8 others onto the > second DMA. Request line numbering is fixed (a peripheral DMA request is > assigned to one MUX input) and but can be routed randomly onto the any 16 > channels. We use chanID to mux input on event. > chanID given by dma_get_any_slave_channe is enough in our case. I would think that if you have in the router node: dma-masters = <&dma1>, <&dma2>; and request a DMA via the router: dmas = <&dma_router req_in param1 param2>; then the router driver would decide which dma-master it is going to assign the given request line and craft the dma-spec based on this decision. This requires no callback to the router from the DMA master driver at all. The idea of the dma event router is to be transparent for the DMA clients (peripherals needing DMA channel) and for the DMA drivers as well. Neither should know that the events are muxed as it does not really matter for them. -- Péter From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Ujfalusi Subject: Re: [PATCH v3 2/5] dmaengine: Add STM32 DMAMUX driver Date: Fri, 4 Aug 2017 17:21:03 +0300 Message-ID: <6e8e19f1-8d0f-183b-e02f-1ec8c4dd57b3@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> <0e16a519-3d60-f683-5517-12a520e0e521@st.com> <71b7ef2a-d745-d16b-4538-567c856cce9a@st.com> <401305f0-15d8-1996-60d6-69c13cbacc06@ti.com> <58bf2f7c-faf1-d1e9-3c87-d7964d1ba3d4@st.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <58bf2f7c-faf1-d1e9-3c87-d7964d1ba3d4@st.com> Content-Language: en-GB 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: Pierre Yves MORDRET , 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 T24gMDgvMDQvMjAxNyAwMzo1MCBQTSwgUGllcnJlIFl2ZXMgTU9SRFJFVCB3cm90ZToKPiBPdXIg RE1BTVVYIGNhbiBtYW5hZ2UgdXAgdG8gMjU1IHJlcXVlc3QgbGluZXMgKG9ubHkgMTI4IGlzIGV2 ZW50dWFsbHkgYXNzaWduZWQKPiB0aG91Z2gpIG9udG8gMTYgZXZlbnRzOiA4IGV2ZW50cyBtYXBw ZWQgb24gMSBETUEgYW5kIHRoZSA4IG90aGVycyBvbnRvIHRoZQo+IHNlY29uZCBETUEuIFJlcXVl c3QgbGluZSBudW1iZXJpbmcgaXMgZml4ZWQgKGEgcGVyaXBoZXJhbCBETUEgcmVxdWVzdCBpcwo+ IGFzc2lnbmVkIHRvIG9uZSBNVVggaW5wdXQpIGFuZCBidXQgY2FuIGJlIHJvdXRlZCByYW5kb21s eSBvbnRvIHRoZSBhbnkgMTYKPiBjaGFubmVscy4gV2UgdXNlIGNoYW5JRCB0byBtdXggaW5wdXQg b24gZXZlbnQuCj4gY2hhbklEIGdpdmVuIGJ5IGRtYV9nZXRfYW55X3NsYXZlX2NoYW5uZSBpcyBl bm91Z2ggaW4gb3VyIGNhc2UuCgpJIHdvdWxkIHRoaW5rIHRoYXQgaWYgeW91IGhhdmUgaW4gdGhl IHJvdXRlciBub2RlOgpkbWEtbWFzdGVycyA9IDwmZG1hMT4sIDwmZG1hMj47CgphbmQgcmVxdWVz dCBhIERNQSB2aWEgdGhlIHJvdXRlcjoKZG1hcyA9IDwmZG1hX3JvdXRlciByZXFfaW4gcGFyYW0x IHBhcmFtMj47Cgp0aGVuIHRoZSByb3V0ZXIgZHJpdmVyIHdvdWxkIGRlY2lkZSB3aGljaCBkbWEt bWFzdGVyIGl0IGlzIGdvaW5nIHRvIGFzc2lnbiB0aGUKZ2l2ZW4gcmVxdWVzdCBsaW5lIGFuZCBj cmFmdCB0aGUgZG1hLXNwZWMgYmFzZWQgb24gdGhpcyBkZWNpc2lvbi4gVGhpcwpyZXF1aXJlcyBu byBjYWxsYmFjayB0byB0aGUgcm91dGVyIGZyb20gdGhlIERNQSBtYXN0ZXIgZHJpdmVyIGF0IGFs bC4KClRoZSBpZGVhIG9mIHRoZSBkbWEgZXZlbnQgcm91dGVyIGlzIHRvIGJlIHRyYW5zcGFyZW50 IGZvciB0aGUgRE1BIGNsaWVudHMKKHBlcmlwaGVyYWxzIG5lZWRpbmcgRE1BIGNoYW5uZWwpIGFu ZCBmb3IgdGhlIERNQSBkcml2ZXJzIGFzIHdlbGwuIE5laXRoZXIKc2hvdWxkIGtub3cgdGhhdCB0 aGUgZXZlbnRzIGFyZSBtdXhlZCBhcyBpdCBkb2VzIG5vdCByZWFsbHkgbWF0dGVyIGZvciB0aGVt LgoKLS0gClDDqXRlcgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18KbGludXgtYXJtLWtlcm5lbCBtYWlsaW5nIGxpc3QKbGludXgtYXJtLWtlcm5lbEBsaXN0 cy5pbmZyYWRlYWQub3JnCmh0dHA6Ly9saXN0cy5pbmZyYWRlYWQub3JnL21haWxtYW4vbGlzdGlu Zm8vbGludXgtYXJtLWtlcm5lbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 From: peter.ujfalusi@ti.com (Peter Ujfalusi) Date: Fri, 4 Aug 2017 17:21:03 +0300 Subject: [PATCH v3 2/5] dmaengine: Add STM32 DMAMUX driver In-Reply-To: <58bf2f7c-faf1-d1e9-3c87-d7964d1ba3d4@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> <71b7ef2a-d745-d16b-4538-567c856cce9a@st.com> <401305f0-15d8-1996-60d6-69c13cbacc06@ti.com> <58bf2f7c-faf1-d1e9-3c87-d7964d1ba3d4@st.com> Message-ID: <6e8e19f1-8d0f-183b-e02f-1ec8c4dd57b3@ti.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 08/04/2017 03:50 PM, Pierre Yves MORDRET wrote: > Our DMAMUX can manage up to 255 request lines (only 128 is eventually assigned > though) onto 16 events: 8 events mapped on 1 DMA and the 8 others onto the > second DMA. Request line numbering is fixed (a peripheral DMA request is > assigned to one MUX input) and but can be routed randomly onto the any 16 > channels. We use chanID to mux input on event. > chanID given by dma_get_any_slave_channe is enough in our case. I would think that if you have in the router node: dma-masters = <&dma1>, <&dma2>; and request a DMA via the router: dmas = <&dma_router req_in param1 param2>; then the router driver would decide which dma-master it is going to assign the given request line and craft the dma-spec based on this decision. This requires no callback to the router from the DMA master driver at all. The idea of the dma event router is to be transparent for the DMA clients (peripherals needing DMA channel) and for the DMA drivers as well. Neither should know that the events are muxed as it does not really matter for them. -- P?ter