From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752418AbdHXNEg (ORCPT ); Thu, 24 Aug 2017 09:04:36 -0400 Received: from mx08-00178001.pphosted.com ([91.207.212.93]:35569 "EHLO mx07-00178001.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751280AbdHXNEe (ORCPT ); Thu, 24 Aug 2017 09:04:34 -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: Thu, 24 Aug 2017 15:03:30 +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: SFHDAG8NODE2.st.com (10.75.127.23) To SFHDAG5NODE2.st.com (10.75.127.14) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-08-24_04:,, signatures=0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08/24/2017 07:47 AM, Peter Ujfalusi wrote: > > > On 2017-08-21 12:34, Pierre Yves MORDRET wrote: >> 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. > > Yes, you should be able to get rid of any custom API. > The DMA event router should be 'invisible' to both the DMA driver itself > and for the DMA users as well. If you end up still needing custom API > (which I doubt) then it is better to extend the core support to cover > that in a generic way since it is likely that other might have similar > needs. > Will see that later on :) > You need to identify what you need to manage with the DMA router, again > in my cases: > am335x/am437x: The DMA channel is fixed, but the DMA event to be handled > by the channel (DMA event muxer) is selected by the router. > dra7x: The DMA event is the fixed part and I needed to translate that to > local eDMA/sDMA events and in eDMA I needed to pick a channel based on > the translated event. > > The same router code works for eDMA and sDMA in dra7, while the two DMA > engines are different in their internal works. > > At the end of the day I only needed to plug the DMA event routers and > there is no change in the DMA drivers at all. > Please tell me whether I'm wrong but for am335x/am437x both DMA Channels and events are given by DT. I believe IP Spec provides the mapping for the channel (this is what you call fixed channel) and DMA router event is selected randomly within the DT. As for dra7 events comes from DT but channel is selected though out local algorithm. IP Spec defines DMA event muxer mapping. At my opinion my router is more closed to dra7. IP Spec defines event mapping. Nonetheless the DMA has a fixed allocated mapping. Using DMA alone DT has to provide channel number. In router mode this number doesn't matter since router makes the routing from fixed event to channel. However router needs to know which channel will be assign to event: any random channel is allowed. I'm pretty sure I can mimic what has been for DRA7 related to DMA Channel allocation however it seems to be this is aside DMA engine. This kind of implementation forbid the use of DMA and DMA router at the same time : I remember you already raise the point. If a DMA channel is requested DMA router is not aware of this allocation. This is the idea of my custom API which relies on get_any_slave_channel(). Using DT to assign channel seems not a good idea either as I lost router's benefice. BTW I need the channel ID within router. Looking at core or of_dma_router_xlate() I don't really know how to do it a generic manner. Ideas are welcomed > I'm happy to answer any questions you might have, if I can. > You will be happy then. > - Péter > Thanks Py