linux-kernel - Re: [PATCH RFC 2/2] ARM: pxa: transition to dmaengine phase 1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 16 Feb 2015 12:33:37 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	linux-arm-kernel@...ts.infradead.org
Cc:	robert.jarzmik@...e.fr, Vinod Koul <vinod.koul@...el.com>,
	linux-kernel@...r.kernel.org,
	Haojian Zhuang <haojian.zhuang@...il.com>,
	Daniel Mack <zonque@...il.com>, dmaengine@...r.kernel.org,
	Olof Johansson <olof@...om.net>
Subject: Re: [PATCH RFC 2/2] ARM: pxa: transition to dmaengine phase 1

On Monday 16 February 2015 12:12:14 robert.jarzmik@...e.fr wrote:
> ----- Mail original -----
> De: "Arnd Bergmann" <arnd@...db.de>
> À: linux-arm-kernel@...ts.infradead.org
> Cc: "Robert Jarzmik" <robert.jarzmik@...e.fr>, "Vinod Koul" <vinod.koul@...el.com>, "Olof Johansson" <olof@...om.net>, "Daniel Mack" <zonque@...il.com>, "Haojian Zhuang" <haojian.zhuang@...il.com>, dmaengine@...r.kernel.org, linux-kernel@...r.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/