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 Content-Length: 1886 Lines: 44 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