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]

Message-ID: <20100502081844.GA7061@n2100.arm.linux.org.uk>
Date:	Sun, 2 May 2010 09:18:44 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Linus Walleij <linus.ml.walleij@...il.com>
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

On Sun, May 02, 2010 at 02:21:13AM +0200, Linus Walleij wrote:
> Yep, that's where it kicks in. (What's the name of this DMA controller
> BTW? Is that PL080?)

It's one of the standard ARM primecells, with a FPGA controlling the
routing of the first three channels.

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

There are two MMCIs on Versatile.

> 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.

Such a scenario leads to two of the three channels assigned to AACI
(one for playback and the other for record - remember, it's full duplex),
leaving one to be shared between the UART Tx and Rx, and two MMCIs.

I'd disagree with you and say that MMCI would be more important than
AACI.  The data rate for MMCI is far higher than AACI - and remember
ARM MMCIs overflow if you don't read the data fast enough.  The MMCI
fmax parameter only exists to put a cap on the rate of the transfer
so that the CPU can read the data fast enough in PIO mode.

However, you only need DMA for MMCI if there's a card inserted in the
slot.  If there's no card in the slot, there's no point starving AACI
of a DMA channel if that's what is being used.
--
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/