From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753238AbdHUJfm (ORCPT ); Mon, 21 Aug 2017 05:35:42 -0400 Received: from mx08-00178001.pphosted.com ([91.207.212.93]:37679 "EHLO mx07-00178001.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752533AbdHUJfk (ORCPT ); Mon, 21 Aug 2017 05:35:40 -0400 Subject: Re: [PATCH v3 2/5] dmaengine: Add STM32 DMAMUX driver 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 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> <6e8e19f1-8d0f-183b-e02f-1ec8c4dd57b3@ti.com> From: Pierre Yves MORDRET Message-ID: Date: Mon, 21 Aug 2017 11:34:15 +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: <6e8e19f1-8d0f-183b-e02f-1ec8c4dd57b3@ti.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.75.127.46] X-ClientProxiedBy: SFHDAG2NODE2.st.com (10.75.127.5) To SFHDAG5NODE2.st.com (10.75.127.14) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-08-21_07:,, signatures=0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08/04/2017 04:21 PM, Peter Ujfalusi wrote: > 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. > OK. I will redesign my driver to take into account this idea. I believe I should get rid of my custom API in DMA for channelID as well. Please confirm. Not very clear for me whether I can keep it or not. Regards 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: Mon, 21 Aug 2017 11:34:15 +0200 Message-ID: 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> <6e8e19f1-8d0f-183b-e02f-1ec8c4dd57b3@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <6e8e19f1-8d0f-183b-e02f-1ec8c4dd57b3-l0cyMroinI0@public.gmane.org> Content-Language: en-US Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Peter Ujfalusi , Vinod Koul Cc: Mark Rutland , "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Amelie DELAUNAY , Alexandre TORGUE , Russell King , Fabien DESSENNE , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "dmaengine-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Rob Herring , Maxime Coquelin , M'boumba Cedric Madianga , Dan Williams , Fabrice GASNIER , "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" , Herbert Xu List-Id: devicetree@vger.kernel.org On 08/04/2017 04:21 PM, Peter Ujfalusi wrote: > 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. > OK. I will redesign my driver to take into account this idea. I believe I should get rid of my custom API in DMA for channelID as well. Please confirm. Not very clear for me whether I can keep it or not. Regards PY -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 From: pierre-yves.mordret@st.com (Pierre Yves MORDRET) Date: Mon, 21 Aug 2017 11:34:15 +0200 Subject: [PATCH v3 2/5] dmaengine: Add STM32 DMAMUX driver In-Reply-To: <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> <6e8e19f1-8d0f-183b-e02f-1ec8c4dd57b3@ti.com> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 08/04/2017 04:21 PM, Peter Ujfalusi wrote: > 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. > OK. I will redesign my driver to take into account this idea. I believe I should get rid of my custom API in DMA for channelID as well. Please confirm. Not very clear for me whether I can keep it or not. Regards PY