From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: Artem Bityutskiy <dedekind1@gmail.com>
Cc: David Woodhouse <dwmw2@infradead.org>,
linux-mtd@lists.infradead.org,
Kyungmin Park <kmpark@infradead.org>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] mtd: OneNAND: samsung: Write DMA support
Date: Thu, 30 Jun 2011 10:19:51 +0100 [thread overview]
Message-ID: <20110630091951.GQ21898@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <1309420530.23597.153.camel@sauron>
On Thu, Jun 30, 2011 at 10:55:25AM +0300, Artem Bityutskiy wrote:
> > + /* Handle vmalloc address */
> > + if (buf >= high_memory) {
> > + struct page *page;
>
> OK, Russell will yell at this, but we do DMA vmalloc'ed addresses for
I most certainly will, because its broken.
> > +
> > + if (((size_t) buf & PAGE_MASK) !=
> > + ((size_t) (buf + count - 1) & PAGE_MASK))
>
> Something is fishy with these size_t casts, could you revisit this piece
> of code - and turn it to something simpler, if possible?
>
> > + goto normal;
> > +
> > + page = vmalloc_to_page(buf);
> > + if (unlikely(!page))
> > + goto normal;
> > +
> > + /* Page offset */
> > + ofs = ((size_t) buf & ~PAGE_MASK);
> > + page_dma = 1;
> > +
> > + /* DMA routine */
> > + dma_src = dma_map_page(dev, page, ofs, count, DMA_TO_DEVICE);
Which is that this code is trying to work around the restriction in the
DMA API that dma_map_single() can only take virtual addresses in the
kernel direct mapped region.
The key thing here is that with CPUs which lookup by virtual address,
like ARMs, you _must_ handle the cache aliases associated with the mapping
which you are accessing the memory via.
This means if you are accessing a DMA buffer at address X, and address X
is cacheable, address X needs cache maintainence performed on it. Address
Y, which may correspond with the same memory as X through a different
mapping is no good. It has to be X.
However, there is NO API for mapping DMA buffers from vmalloc space.
What we do now have are a pair of functions which must be used _correctly_
(iow, one before and one after) to ensure that virtual cached architectures
can access the data correctly - and its documented at the bottom of
cachetlb.txt.
As this is something which keeps coming up in connection with MTD, it
may be a good idea if MTD gave driver authors a helping hand with DMA
setup/teardown so that the chances of driver authors getting this right
is greater...
next prev parent reply other threads:[~2011-06-30 9:20 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-08 10:18 [PATCH] mtd: OneNAND: samsung: Write DMA support Kyungmin Park
2011-06-29 7:22 ` Kyungmin Park
2011-06-30 7:21 ` Artem Bityutskiy
2011-06-30 7:55 ` Artem Bityutskiy
2011-06-30 9:19 ` Russell King - ARM Linux [this message]
2011-06-30 10:45 ` Artem Bityutskiy
2011-06-30 11:23 ` Russell King - ARM Linux
2011-06-30 13:38 ` Artem Bityutskiy
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=20110630091951.GQ21898@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=dedekind1@gmail.com \
--cc=dwmw2@infradead.org \
--cc=kmpark@infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mtd@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