From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932300AbbBPLdu (ORCPT ); Mon, 16 Feb 2015 06:33:50 -0500 Received: from mout.kundenserver.de ([212.227.17.24]:59906 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754930AbbBPLdt convert rfc822-to-8bit (ORCPT ); Mon, 16 Feb 2015 06:33:49 -0500 From: Arnd Bergmann To: linux-arm-kernel@lists.infradead.org Cc: robert.jarzmik@free.fr, Vinod Koul , linux-kernel@vger.kernel.org, Haojian Zhuang , Daniel Mack , dmaengine@vger.kernel.org, Olof Johansson Subject: Re: [PATCH RFC 2/2] ARM: pxa: transition to dmaengine phase 1 Date: Mon, 16 Feb 2015 12:33:37 +0100 Message-ID: <13207901.k8BLLCXjzv@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <1627069656.469844934.1424085134263.JavaMail.root@zimbra1-e1.priv.proxad.net> References: <1627069656.469844934.1424085134263.JavaMail.root@zimbra1-e1.priv.proxad.net> MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT Content-Type: text/plain; charset="iso-8859-1" X-Provags-ID: V03:K0:lL0STZNwXNyoze9b5+QDccN6ysXHKcYYq9vBs22IEuVKnRB3HKM zQkLs+M8Rc23ygOMqr53KfvU8vG2Zu3YDI0KgbBBT9CvIjoUPEezPyFI8Jw/2if8SHGjb9R MmPeAwYFuC24flsIfXvpOkC0P4gpKF0FfioD3AVQHf/VCIBBasJ3zGIe0+0HdpeQlADba+q VIugIHCoFTwbd8XNPcaIg== X-UI-Out-Filterresults: notjunk:1; Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Monday 16 February 2015 12:12:14 robert.jarzmik@free.fr wrote: > ----- Mail original ----- > De: "Arnd Bergmann" > À: linux-arm-kernel@lists.infradead.org > Cc: "Robert Jarzmik" , "Vinod Koul" , "Olof Johansson" , "Daniel Mack" , "Haojian Zhuang" , dmaengine@vger.kernel.org, linux-kernel@vger.kernel.org > Envoyé: Lundi 16 Février 2015 11:28:57 > Objet: Re: [PATCH RFC 2/2] ARM: pxa: transition to dmaengine phase 1 > > On Saturday 14 February 2015 23:47:33 Robert Jarzmik wrote: > >> @@ -294,7 +294,8 @@ int pxa_request_dma (char *name, pxa_dma_prio prio, > >> /* try grabbing a DMA channel with the requested priority */ > >> for (i = 0; i < num_dma_channels; i++) { > >> if ((dma_channels[i].prio == prio) && > >> - !dma_channels[i].name) { > >> + !dma_channels[i].name && > >> + !mmp_pdma_toggle_reserved_channel(i)) { > >> found = 1; > >> break; > >> } > >> > > > How is the order between the two enforced? I.e. can it be that the dmaengine > > driver uses the same channel for a different slave before we get here? > > If a request is made for a "low prio channel", ie. channel 8, 9 or 10 if I remember > correctly : > - suppose dmaengine has transactions underway, and channel 8 is busy > - this loop, for i == 8 : mmp_pdma_toggle_reserved_channel(8) -> -EBUSY > - loop continues, i == 9 : mmp_pdma_toggle_reserved_channel(8) -> 0 > => pxa_request_dma reserves channel 9 > > From now on, mmp_pdma will "skip" channel 9 from its candidates to serve requests. Ah, so the function asks for just one channel of the right priority, not a particular channel. I missed that detail. > > If this is ensured to work, I'm fine with your approach. > Actually it does. Not exactly this version, as the mmp_pdma interrupt was a bit > amended to "skip" also reserved channels and not steal events from legacy code, > but that will be for official submission. > > It's also designed to be race free, relying on the fact that there is only one > CPU on pxa{2,3}xx SocS (irq_save covers). Ok. > I'm testing it right now with 2 drivers : > - pxa3xx_nand, which is converted to dmaengine > - pxamci, which is not converted to dmaengine > In 3 variants : > - zylonite pxa3xx board booted with device-tree > - zylonite pxa3xx board booted in legacy > - mioa701 board booted in device-tree > > So far so good. If the mmp_pdma patch is accepted for the transition, it will > open up my path towards dmaengine conversion of all pxa drivers (mmc, nand, > pxa_camera and pxa2xx-pcm-lib). As Daniel has already done most of the work, > and because I have kept it for 2 years, that part will be less a burden than > it would seem ... Ok, great! > only the camera will give me a small headache. Let's worry about that when all the other ones are done then ;-) Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 From: arnd@arndb.de (Arnd Bergmann) Date: Mon, 16 Feb 2015 12:33:37 +0100 Subject: [PATCH RFC 2/2] ARM: pxa: transition to dmaengine phase 1 In-Reply-To: <1627069656.469844934.1424085134263.JavaMail.root@zimbra1-e1.priv.proxad.net> References: <1627069656.469844934.1424085134263.JavaMail.root@zimbra1-e1.priv.proxad.net> Message-ID: <13207901.k8BLLCXjzv@wuerfel> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Monday 16 February 2015 12:12:14 robert.jarzmik at free.fr wrote: > ----- Mail original ----- > De: "Arnd Bergmann" > ?: linux-arm-kernel at lists.infradead.org > Cc: "Robert Jarzmik" , "Vinod Koul" , "Olof Johansson" , "Daniel Mack" , "Haojian Zhuang" , dmaengine at vger.kernel.org, linux-kernel at vger.kernel.org > Envoy?: Lundi 16 F?vrier 2015 11:28:57 > Objet: Re: [PATCH RFC 2/2] ARM: pxa: transition to dmaengine phase 1 > > On Saturday 14 February 2015 23:47:33 Robert Jarzmik wrote: > >> @@ -294,7 +294,8 @@ int pxa_request_dma (char *name, pxa_dma_prio prio, > >> /* try grabbing a DMA channel with the requested priority */ > >> for (i = 0; i < num_dma_channels; i++) { > >> if ((dma_channels[i].prio == prio) && > >> - !dma_channels[i].name) { > >> + !dma_channels[i].name && > >> + !mmp_pdma_toggle_reserved_channel(i)) { > >> found = 1; > >> break; > >> } > >> > > > How is the order between the two enforced? I.e. can it be that the dmaengine > > driver uses the same channel for a different slave before we get here? > > If a request is made for a "low prio channel", ie. channel 8, 9 or 10 if I remember > correctly : > - suppose dmaengine has transactions underway, and channel 8 is busy > - this loop, for i == 8 : mmp_pdma_toggle_reserved_channel(8) -> -EBUSY > - loop continues, i == 9 : mmp_pdma_toggle_reserved_channel(8) -> 0 > => pxa_request_dma reserves channel 9 > > From now on, mmp_pdma will "skip" channel 9 from its candidates to serve requests. Ah, so the function asks for just one channel of the right priority, not a particular channel. I missed that detail. > > If this is ensured to work, I'm fine with your approach. > Actually it does. Not exactly this version, as the mmp_pdma interrupt was a bit > amended to "skip" also reserved channels and not steal events from legacy code, > but that will be for official submission. > > It's also designed to be race free, relying on the fact that there is only one > CPU on pxa{2,3}xx SocS (irq_save covers). Ok. > I'm testing it right now with 2 drivers : > - pxa3xx_nand, which is converted to dmaengine > - pxamci, which is not converted to dmaengine > In 3 variants : > - zylonite pxa3xx board booted with device-tree > - zylonite pxa3xx board booted in legacy > - mioa701 board booted in device-tree > > So far so good. If the mmp_pdma patch is accepted for the transition, it will > open up my path towards dmaengine conversion of all pxa drivers (mmc, nand, > pxa_camera and pxa2xx-pcm-lib). As Daniel has already done most of the work, > and because I have kept it for 2 years, that part will be less a burden than > it would seem ... Ok, great! > only the camera will give me a small headache. Let's worry about that when all the other ones are done then ;-) Arnd