From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751739AbdHCGmx (ORCPT ); Thu, 3 Aug 2017 02:42:53 -0400 Received: from fllnx210.ext.ti.com ([198.47.19.17]:54651 "EHLO fllnx210.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751079AbdHCGmu (ORCPT ); Thu, 3 Aug 2017 02:42:50 -0400 Subject: Re: [PATCH v3 2/5] dmaengine: Add STM32 DMAMUX driver To: Pierre Yves MORDRET , Vinod Koul 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> 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" From: Peter Ujfalusi Message-ID: Date: Thu, 3 Aug 2017 09:42:04 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <0e16a519-3d60-f683-5517-12a520e0e521@st.com> Content-Type: text/plain; charset="utf-8"; format=flowed X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nfs id v736h0FE020450 our mail server started to mangle outgoing mails, sorry for that, we are trying to resolve that... Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki On 2017-08-02 17:28, Pierre Yves MORDRET wrote: > 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... What I actually mean is that you should not need to modify the DMA driver at all. According to stm32-dma.txt: #dma-cells = <4>; 1. channelID 2. request line number 3. - 4. some parameters I believe if you don't have the event router (directly using the DMA node) you always need to provide these, right? If I'm not mistaken, when you use the event router you want to omit the ChannelID and get a random channel via dma_get_any_slave_channel in the DMA driver and feed back the channelID to the event router driver? I believe the reason for this is that you want to keep mixed binding use, to have direct DMA bindings and bindings via event router. Now what happens if you have direct binding: device1 { dmas = <&dma2 1 4 0x10400 0x3>; }; and via event router: device2 { dmas = <&dma_router 10 0x10400 0x3>, <&dma_router 11 0x10400 0x3>; }; device2 probes first, will get channelID 0 and 1 via dma_get_any_slave_channel. When device1 tries to probe, the channelID 1 is already taken.. You need to convert all peripherals to use the event router to avoid such a races. I have done the same for the dra7. Add the event router driver, add the event router node and convert existing users to use that when adding new devices, use the event router node. The event router's binding would have 3 parameters, it manages the available channelIDs, like the ti-dma-crossbar does for dra7. At allocate time it would pick an unused channelID and craft the dma-spec with the four parameters as documented. The main DMA driver will not need any modification as everything will be taken care of by the event router. The only gotcha is with memcpy type of transfers as they might also need unique channelID, but not requested via the slave binding. For that I have added properties to the event router to mask out certain channels (and I needed to do the same for the eDMA, but it is unrelated to the router itself). - 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: Thu, 3 Aug 2017 09:42:04 +0300 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> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; Format="flowed" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <0e16a519-3d60-f683-5517-12a520e0e521@st.com> 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 77u/b3VyIG1haWwgc2VydmVyIHN0YXJ0ZWQgdG8gbWFuZ2xlIG91dGdvaW5nIG1haWxzLCBzb3Jy eSBmb3IgdGhhdCwgd2UgYXJlIAp0cnlpbmcgdG8gcmVzb2x2ZSB0aGF0Li4uCgoKVGV4YXMgSW5z dHJ1bWVudHMgRmlubGFuZCBPeSwgUG9ya2thbGFua2F0dSAyMiwgMDAxODAgSGVsc2lua2kuIFkt dHVubnVzL0J1c2luZXNzIElEOiAwNjE1NTIxLTQuIEtvdGlwYWlra2EvRG9taWNpbGU6IEhlbHNp bmtpCgpPbiAyMDE3LTA4LTAyIDE3OjI4LCBQaWVycmUgWXZlcyBNT1JEUkVUIHdyb3RlOgo+IENv cnJlY3Qgcm91dGVyIG5lZWRzIDMgcGFyYW1ldGVycyBhbmQgYW1vbmcgdGhvc2UgMiBhcmUgZm9y d2FyZGVkIHRob3VnaCBvdXQKPiBkbWFfc3BlYy4gQnV0IHdoZW4geW91IHNheSAiQ2hhbm5lbElE IGlzIGR5bmFtaWNhbGx5IGFsbG9jYXRlZCIgeW91IG1lYW4KPiBkbWFfZ2V0X2FueV9zbGF2ZV9j aGFubmVsID8gSWYgeWVzIEkgY2FuIHVzZSB0aGUgYWxyZWFkeSBleGlzdGluZyBiaW5kaW5ncyB0 bwo+IGNhcnJ5IHRoZSBjaGFubmVsSUQgdG8gRE1BLiBObyBjaGFuZ2VzIG5lZWQgdG8gcGVyaXBo ZXJhbC4uLgoKV2hhdCBJIGFjdHVhbGx5IG1lYW4gaXMgdGhhdCB5b3Ugc2hvdWxkIG5vdCBuZWVk IHRvIG1vZGlmeSB0aGUgRE1BIApkcml2ZXIgYXQgYWxsLgpBY2NvcmRpbmcgdG8gc3RtMzItZG1h LnR4dDoKI2RtYS1jZWxscyA9IDw0PjsKMS4gY2hhbm5lbElECjIuIHJlcXVlc3QgbGluZSBudW1i ZXIKMy4gLSA0LiBzb21lIHBhcmFtZXRlcnMKCkkgYmVsaWV2ZSBpZiB5b3UgZG9uJ3QgaGF2ZSB0 aGUgZXZlbnQgcm91dGVyIChkaXJlY3RseSB1c2luZyB0aGUgRE1BIApub2RlKSB5b3UgYWx3YXlz IG5lZWQgdG8gcHJvdmlkZSB0aGVzZSwgcmlnaHQ/CklmIEknbSBub3QgbWlzdGFrZW4sIHdoZW4g eW91IHVzZSB0aGUgZXZlbnQgcm91dGVyIHlvdSB3YW50IHRvIG9taXQgdGhlIApDaGFubmVsSUQg YW5kIGdldCBhIHJhbmRvbSBjaGFubmVsIHZpYSBkbWFfZ2V0X2FueV9zbGF2ZV9jaGFubmVsIGlu IHRoZSAKRE1BIGRyaXZlciBhbmQgZmVlZCBiYWNrIHRoZSBjaGFubmVsSUQgdG8gdGhlIGV2ZW50 IHJvdXRlciBkcml2ZXI/CkkgYmVsaWV2ZSB0aGUgcmVhc29uIGZvciB0aGlzIGlzIHRoYXQgeW91 IHdhbnQgdG8ga2VlcCBtaXhlZCBiaW5kaW5nIAp1c2UsIHRvIGhhdmUgZGlyZWN0IERNQSBiaW5k aW5ncyBhbmQgYmluZGluZ3MgdmlhIGV2ZW50IHJvdXRlci4KCk5vdyB3aGF0IGhhcHBlbnMgaWYg eW91IGhhdmUgZGlyZWN0IGJpbmRpbmc6CmRldmljZTEgewoJZG1hcyA9IDwmZG1hMiAxIDQgMHgx MDQwMCAweDM+Owp9OwoKYW5kIHZpYSBldmVudCByb3V0ZXI6CmRldmljZTIgewoJZG1hcyA9CTwm ZG1hX3JvdXRlciAxMCAweDEwNDAwIDB4Mz4sCgkJPCZkbWFfcm91dGVyIDExIDB4MTA0MDAgMHgz PjsKfTsKCmRldmljZTIgcHJvYmVzIGZpcnN0LCB3aWxsIGdldCBjaGFubmVsSUQgMCBhbmQgMSB2 aWEgCmRtYV9nZXRfYW55X3NsYXZlX2NoYW5uZWwuCgpXaGVuIGRldmljZTEgdHJpZXMgdG8gcHJv YmUsIHRoZSBjaGFubmVsSUQgMSBpcyBhbHJlYWR5IHRha2VuLi4KCllvdSBuZWVkIHRvIGNvbnZl cnQgYWxsIHBlcmlwaGVyYWxzIHRvIHVzZSB0aGUgZXZlbnQgcm91dGVyIHRvIGF2b2lkIApzdWNo IGEgcmFjZXMuIEkgaGF2ZSBkb25lIHRoZSBzYW1lIGZvciB0aGUgZHJhNy4KQWRkIHRoZSBldmVu dCByb3V0ZXIgZHJpdmVyLAphZGQgdGhlIGV2ZW50IHJvdXRlciBub2RlIGFuZCBjb252ZXJ0IGV4 aXN0aW5nIHVzZXJzIHRvIHVzZSB0aGF0CndoZW4gYWRkaW5nIG5ldyBkZXZpY2VzLCB1c2UgdGhl IGV2ZW50IHJvdXRlciBub2RlLgoKVGhlIGV2ZW50IHJvdXRlcidzIGJpbmRpbmcgd291bGQgaGF2 ZSAzIHBhcmFtZXRlcnMsIGl0IG1hbmFnZXMgdGhlIAphdmFpbGFibGUgY2hhbm5lbElEcywgbGlr ZSB0aGUgdGktZG1hLWNyb3NzYmFyIGRvZXMgZm9yIGRyYTcuIEF0IAphbGxvY2F0ZSB0aW1lIGl0 IHdvdWxkIHBpY2sgYW4gdW51c2VkIGNoYW5uZWxJRCBhbmQgY3JhZnQgdGhlIGRtYS1zcGVjIAp3 aXRoIHRoZSBmb3VyIHBhcmFtZXRlcnMgYXMgZG9jdW1lbnRlZC4KVGhlIG1haW4gRE1BIGRyaXZl ciB3aWxsIG5vdCBuZWVkIGFueSBtb2RpZmljYXRpb24gYXMgZXZlcnl0aGluZyB3aWxsIGJlIAp0 YWtlbiBjYXJlIG9mIGJ5IHRoZSBldmVudCByb3V0ZXIuCgpUaGUgb25seSBnb3RjaGEgaXMgd2l0 aCBtZW1jcHkgdHlwZSBvZiB0cmFuc2ZlcnMgYXMgdGhleSBtaWdodCBhbHNvIG5lZWQgCnVuaXF1 ZSBjaGFubmVsSUQsIGJ1dCBub3QgcmVxdWVzdGVkIHZpYSB0aGUgc2xhdmUgYmluZGluZy4gRm9y IHRoYXQgSSAKaGF2ZSBhZGRlZCBwcm9wZXJ0aWVzIHRvIHRoZSBldmVudCByb3V0ZXIgdG8gbWFz ayBvdXQgY2VydGFpbiBjaGFubmVscyAKKGFuZCBJIG5lZWRlZCB0byBkbyB0aGUgc2FtZSBmb3Ig dGhlIGVETUEsIGJ1dCBpdCBpcyB1bnJlbGF0ZWQgdG8gdGhlIApyb3V0ZXIgaXRzZWxmKS4KCgot IFDDqXRlcgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f CmxpbnV4LWFybS1rZXJuZWwgbWFpbGluZyBsaXN0CmxpbnV4LWFybS1rZXJuZWxAbGlzdHMuaW5m cmFkZWFkLm9yZwpodHRwOi8vbGlzdHMuaW5mcmFkZWFkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xp bnV4LWFybS1rZXJuZWwK From mboxrd@z Thu Jan 1 00:00:00 1970 From: peter.ujfalusi@ti.com (Peter Ujfalusi) Date: Thu, 3 Aug 2017 09:42:04 +0300 Subject: [PATCH v3 2/5] dmaengine: Add STM32 DMAMUX driver In-Reply-To: <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> <0e16a519-3d60-f683-5517-12a520e0e521@st.com> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org ?our mail server started to mangle outgoing mails, sorry for that, we are trying to resolve that... Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki On 2017-08-02 17:28, Pierre Yves MORDRET wrote: > 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... What I actually mean is that you should not need to modify the DMA driver at all. According to stm32-dma.txt: #dma-cells = <4>; 1. channelID 2. request line number 3. - 4. some parameters I believe if you don't have the event router (directly using the DMA node) you always need to provide these, right? If I'm not mistaken, when you use the event router you want to omit the ChannelID and get a random channel via dma_get_any_slave_channel in the DMA driver and feed back the channelID to the event router driver? I believe the reason for this is that you want to keep mixed binding use, to have direct DMA bindings and bindings via event router. Now what happens if you have direct binding: device1 { dmas = <&dma2 1 4 0x10400 0x3>; }; and via event router: device2 { dmas = <&dma_router 10 0x10400 0x3>, <&dma_router 11 0x10400 0x3>; }; device2 probes first, will get channelID 0 and 1 via dma_get_any_slave_channel. When device1 tries to probe, the channelID 1 is already taken.. You need to convert all peripherals to use the event router to avoid such a races. I have done the same for the dra7. Add the event router driver, add the event router node and convert existing users to use that when adding new devices, use the event router node. The event router's binding would have 3 parameters, it manages the available channelIDs, like the ti-dma-crossbar does for dra7. At allocate time it would pick an unused channelID and craft the dma-spec with the four parameters as documented. The main DMA driver will not need any modification as everything will be taken care of by the event router. The only gotcha is with memcpy type of transfers as they might also need unique channelID, but not requested via the slave binding. For that I have added properties to the event router to mask out certain channels (and I needed to do the same for the eDMA, but it is unrelated to the router itself). - P?ter