From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] mmci: restrict DMA usage to large, even multiblock transfers
Date: Tue, 1 Feb 2011 14:44:37 +0000 [thread overview]
Message-ID: <20110201144437.GL31216@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <AANLkTimN=bxJzGFDc50-ZUMmCtXaGxVUd9-Zg1+QGfNf@mail.gmail.com>
On Tue, Feb 01, 2011 at 03:07:12PM +0100, Linus Walleij wrote:
> 2011/2/1 Russell King - ARM Linux <linux@arm.linux.org.uk>:
>
> > So... I think this patch will work fine on ST variants, returning the
> > DMA request signals back to their classic meaning. ?That being LSREQ
> > is only activated on the _final_ transfer rather than the last 8
> > transfers, which as Linus describes makes your DMA controller complete
> > on the 8th-to-last transfer.
>
> I've tested this patch on MMC and SD on U8500 and it works
> fine, so
> Tested-by: Linus Walleij <linus.walleij@linaro.org>
>
> However I think this weird bit turning off all single requests
> is there for some reason and I still try to find out what the
> usecase really is. I highly suspect that it's related to either
> doing some SDIO usecase or pleasing some buggy DMA
> controller.
We aren't turning off single requests - by clearing DMAREQCTL, we're
actually turning them back on.
What I think is going on is someone had an idea of using LBREQ to
transfer the last one to seven transfers as a burst, rather than one
to seven separate single transfers as an optimization. However, this
can only work if the DMA controller obeys the transfer count and doesn't
try to transfer more than the remainder of the transfer in any burst.
IOW, the DMAC has to truncate bursts to the smaller of the burst size
and remainder. If it can't, DMAREQCTL causes problems.
I assume that the U8500/U300 documentation isn't publically available...
A quick google doesn't seem to help.
next prev parent reply other threads:[~2011-02-01 14:44 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-01 10:41 [PATCH] mmci: restrict DMA usage to large, even multiblock transfers Linus Walleij
2011-02-01 10:54 ` Russell King - ARM Linux
2011-02-01 11:34 ` Ulf Hansson
2011-02-01 11:45 ` Russell King - ARM Linux
2011-02-01 11:56 ` Ulf Hansson
2011-02-01 11:58 ` Russell King - ARM Linux
2011-02-01 14:07 ` Linus Walleij
2011-02-01 14:44 ` Russell King - ARM Linux [this message]
2011-02-02 9:39 ` Linus Walleij
2011-02-01 15:05 ` Russell King - ARM Linux
2011-02-02 9:34 ` Linus Walleij
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=20110201144437.GL31216@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=linux-arm-kernel@lists.infradead.org \
/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).