linux-kernel - Re: [PATCH 00/11] ARM: PrimeCell DMA Interface v5

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:	Sun, 2 May 2010 02:21:13 +0200
From:	Linus Walleij <linus.ml.walleij@...il.com>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	Dan Williams <dan.j.williams@...el.com>,
	Linus WALLEIJ <linus.walleij@...ricsson.com>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	Grant Likely <grant.likely@...retlab.ca>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
	STEricsson_nomadik_linux <STEricsson_nomadik_linux@...t.st.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 00/11] ARM: PrimeCell DMA Interface v5

2010/5/2 Russell King - ARM Linux <linux@....linux.org.uk>:

>> But the implementation of the DMA engine would be better of
>> handling the muxing dynamically I believe, so when the PL011
>> driver (say) requests a DMA channel, it doesn't mean it requests the
>> *physical* channel and holds it (unless the driver is very naďvely
>> implemented) it nominally means it reserves a placeholder in the
>> DMA engine.
>
> So what happens if we try to use DMA with the PL011 but the physical
> channels are already in use?  From what I can see, it assumes that it
> always has access to the transmit channel, and there's no recovery if
> it doesn't.
>
> Plus if we can't get DMA for the RX path, it _permanently_ disables
> all DMA for the device.

OK now I get it.. the point of crux is that you need the drivers to be
coded to switch seamlessly back to interrupt mode and retry with
DMA on next transaction nevertheless if possible.

That is definately possible with the current API, so it's nothing blocking
the stuff pending in Dan's tree.

However when it comes to the PL011/PL180 drivers you got me there,
it surely does assume you either have the channel and can use it
or else there is some permanent error on it.

I'll twist these patches around a bit, it shouldn't be too hard to come up
with some convincing code.

> Three physical channels shared between: AACI Tx, AACI Rx, MMCI 0, MMCI 1,
> UART3 Tx, UART3 Rx.
> (...)
> All you need is to load both the AACI
> and MMCI drivers, and if they want to use the DMA channels, you're
> already wanting 4 channels with only 3 available.

Yep, that's where it kicks in. (What's the name of this DMA controller
BTW? Is that PL080?)

(I read it as MMCI is bidirectional also on the Versatile, as it is
on the U300.)

However: this way of using the DMA dynamically instead of statically
leads to the situation where a UART or two MMCs are using up the
DMA channels and AACI cannot use it, and need to fall back to
interrupts. Since the Audio traffic is likely to be more important, this
is perhaps not so optimal, so a static assignment of DMA channels
may be desired after all in a practical scenario.

But I'll surely make a try to make all DMA allocation from the
PrimeCells dynamic!

Yours,
Linus Walleij
--
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/