linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Walleij <linus.ml.walleij@gmail.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Dan Williams <dan.j.williams@intel.com>,
	Linus WALLEIJ <linus.walleij@stericsson.com>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	Grant Likely <grant.likely@secretlab.ca>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
	STEricsson_nomadik_linux <STEricsson_nomadik_linux@list.st.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 00/11] ARM: PrimeCell DMA Interface v5
Date: Sun, 2 May 2010 02:21:13 +0200	[thread overview]
Message-ID: <r2u63386a3d1005011721v66d04172nc0e5163115006267@mail.gmail.com> (raw)
In-Reply-To: <20100501232823.GB17693@n2100.arm.linux.org.uk>

2010/5/2 Russell King - ARM Linux <linux@arm.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

  reply	other threads:[~2010-05-02  0:21 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-07 23:12 [PATCH 00/11] ARM: PrimeCell DMA Interface v5 Linus Walleij
2010-04-07 23:45 ` Dan Williams
2010-04-08  6:35   ` Linus WALLEIJ
2010-04-11 14:13     ` Linus Walleij
2010-04-12 19:23       ` Russell King - ARM Linux
2010-04-15  1:15     ` Dan Williams
2010-04-17  4:58       ` Linus Walleij
2010-04-22 11:00         ` Russell King - ARM Linux
2010-04-30 18:30           ` Linus Walleij
2010-05-01 22:00           ` Dan Williams
2010-05-01 22:27             ` Linus Walleij
2010-05-01 22:44             ` Russell King - ARM Linux
2010-05-01 23:04               ` Linus Walleij
2010-05-01 23:28                 ` Russell King - ARM Linux
2010-05-02  0:21                   ` Linus Walleij [this message]
2010-05-02  8:18                     ` Russell King - ARM Linux
2010-05-04 13:05                       ` Linus WALLEIJ
2010-05-01 23:28                 ` Dan Williams
2010-05-01 23:48                   ` Linus Walleij
2010-05-01 23:25               ` Dan Williams

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=r2u63386a3d1005011721v66d04172nc0e5163115006267@mail.gmail.com \
    --to=linus.ml.walleij@gmail.com \
    --cc=STEricsson_nomadik_linux@list.st.com \
    --cc=akpm@linux-foundation.org \
    --cc=dan.j.williams@intel.com \
    --cc=grant.likely@secretlab.ca \
    --cc=linus.walleij@stericsson.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    /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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).