From: Arnd Bergmann <arnd@arndb.de> To: linux-arm-kernel@lists.infradead.org Cc: robert.jarzmik@free.fr, Vinod Koul <vinod.koul@intel.com>, linux-kernel@vger.kernel.org, Haojian Zhuang <haojian.zhuang@gmail.com>, Daniel Mack <zonque@gmail.com>, dmaengine@vger.kernel.org, Olof Johansson <olof@lixom.net> Subject: Re: [PATCH RFC 2/2] ARM: pxa: transition to dmaengine phase 1 Date: Mon, 16 Feb 2015 12:33:37 +0100 [thread overview] Message-ID: <13207901.k8BLLCXjzv@wuerfel> (raw) In-Reply-To: <1627069656.469844934.1424085134263.JavaMail.root@zimbra1-e1.priv.proxad.net> On Monday 16 February 2015 12:12:14 robert.jarzmik@free.fr wrote: > ----- Mail original ----- > De: "Arnd Bergmann" <arnd@arndb.de> > À: linux-arm-kernel@lists.infradead.org > Cc: "Robert Jarzmik" <robert.jarzmik@free.fr>, "Vinod Koul" <vinod.koul@intel.com>, "Olof Johansson" <olof@lixom.net>, "Daniel Mack" <zonque@gmail.com>, "Haojian Zhuang" <haojian.zhuang@gmail.com>, 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
WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH RFC 2/2] ARM: pxa: transition to dmaengine phase 1 Date: Mon, 16 Feb 2015 12:33:37 +0100 [thread overview] Message-ID: <13207901.k8BLLCXjzv@wuerfel> (raw) In-Reply-To: <1627069656.469844934.1424085134263.JavaMail.root@zimbra1-e1.priv.proxad.net> On Monday 16 February 2015 12:12:14 robert.jarzmik at free.fr wrote: > ----- Mail original ----- > De: "Arnd Bergmann" <arnd@arndb.de> > ?: linux-arm-kernel at lists.infradead.org > Cc: "Robert Jarzmik" <robert.jarzmik@free.fr>, "Vinod Koul" <vinod.koul@intel.com>, "Olof Johansson" <olof@lixom.net>, "Daniel Mack" <zonque@gmail.com>, "Haojian Zhuang" <haojian.zhuang@gmail.com>, 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
next prev parent reply other threads:[~2015-02-16 11:33 UTC|newest] Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-02-14 22:47 [PATCH RFC 0/2] Prepare smooth PXA transition to dmaengine Robert Jarzmik 2015-02-14 22:47 ` Robert Jarzmik 2015-02-14 22:47 ` [PATCH RFC 1/2] dma: mmp_dma: add support for legacy transition Robert Jarzmik 2015-02-14 22:47 ` Robert Jarzmik 2015-02-14 22:47 ` [PATCH RFC 2/2] ARM: pxa: transition to dmaengine phase 1 Robert Jarzmik 2015-02-14 22:47 ` Robert Jarzmik 2015-02-16 10:28 ` Arnd Bergmann 2015-02-16 10:28 ` Arnd Bergmann 2015-02-16 11:12 ` robert.jarzmik 2015-02-16 11:12 ` robert.jarzmik at free.fr 2015-02-16 11:33 ` Arnd Bergmann [this message] 2015-02-16 11:33 ` Arnd Bergmann 2015-02-16 11:37 ` Daniel Mack 2015-02-16 11:37 ` Daniel Mack 2015-02-16 11:14 ` Vasily Khoruzhick 2015-02-16 11:14 ` Vasily Khoruzhick 2015-02-16 11:23 ` Daniel Mack 2015-02-16 11:23 ` Daniel Mack 2015-02-16 16:54 ` Robert Jarzmik 2015-02-16 16:54 ` Robert Jarzmik 2015-02-16 17:00 ` Vasily Khoruzhick 2015-02-16 17:00 ` Vasily Khoruzhick 2015-02-16 18:03 ` Robert Jarzmik 2015-02-16 18:03 ` Robert Jarzmik 2015-02-17 20:39 ` [PATCH v2 1/2] dma: mmp_dma: add support for legacy transition Robert Jarzmik 2015-02-17 20:39 ` Robert Jarzmik 2015-02-17 20:39 ` [PATCH v2 2/2] ARM: pxa: transition to dmaengine phase 1 Robert Jarzmik 2015-02-17 20:39 ` Robert Jarzmik 2015-02-19 10:29 ` [PATCH v2 1/2] dma: mmp_dma: add support for legacy transition Daniel Mack 2015-02-19 10:29 ` Daniel Mack 2015-02-19 19:53 ` Robert Jarzmik 2015-02-19 19:53 ` Robert Jarzmik
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=13207901.k8BLLCXjzv@wuerfel \ --to=arnd@arndb.de \ --cc=dmaengine@vger.kernel.org \ --cc=haojian.zhuang@gmail.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=olof@lixom.net \ --cc=robert.jarzmik@free.fr \ --cc=vinod.koul@intel.com \ --cc=zonque@gmail.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.