From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linus Walleij Subject: Re: [PATCH 00/11] ARM: PrimeCell DMA Interface v5 Date: Sun, 2 May 2010 02:21:13 +0200 Message-ID: References: <1270681920-4461-1-git-send-email-linus.walleij@stericsson.com> <20100422110025.GC20008@n2100.arm.linux.org.uk> <20100501224429.GA17693@n2100.arm.linux.org.uk> <20100501232823.GB17693@n2100.arm.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Received: from mail-bw0-f219.google.com ([209.85.218.219]:40112 "EHLO mail-bw0-f219.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753912Ab0EBAVO convert rfc822-to-8bit (ORCPT ); Sat, 1 May 2010 20:21:14 -0400 In-Reply-To: <20100501232823.GB17693@n2100.arm.linux.org.uk> Sender: linux-mmc-owner@vger.kernel.org List-Id: linux-mmc@vger.kernel.org To: Russell King - ARM Linux Cc: Dan Williams , Linus WALLEIJ , "akpm@linux-foundation.org" , Grant Likely , "linux-arm-kernel@lists.infradead.org" , "linux-mmc@vger.kernel.org" , STEricsson_nomadik_linux , "linux-kernel@vger.kernel.org" 2010/5/2 Russell King - ARM Linux : >> 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=C4=8Fv= ely >> 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? =C2=A0From what I can see, it assumes th= at 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 block= ing 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, MMC= I 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, thi= s 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