From: John Williams <john.williams@petalogix.com>
To: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
Cc: arnd@arndb.de, linux-arch@vger.kernel.org,
John Linn <linnj@xilinx.com>,
matthew@wil.cx, will.newton@gmail.com, drepper@redhat.com,
microblaze-uclinux@itee.uq.edu.au, grant.likely@secretlab.ca,
Michal Simek <monstr@monstr.eu>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Microblaze: implement dma-coherent API and refactor cache flush code.
Date: Tue, 06 May 2008 08:57:17 +1000 [thread overview]
Message-ID: <1210028237.5798.121.camel@localhost> (raw)
In-Reply-To: <20080505223706.1236C1C8004E@mail131-sin.bigfish.com>
Hi Steve,
On Mon, 2008-05-05 at 15:37 -0700, Stephen Neuendorffer wrote:
> In particular, the dcache in the microblaze is write through, so the
> existing code is more easily thought of as 'invalidation' than
> 'flushing'. In addition, some of the flush_* methods were old, and
> some shouldn't need to be implemented (since currently no mmu is
> supported).
I agree - this renaming is a long time coming.
[snip]
Does the DMA API insist upon the dma_cache_sync call to guarantee
sensible results? If so, your implementation looks fine. If not, then
the results will clearly be bogus as there's nothing magical about the
memory being allocated in dma_alloc.
To that end, can it just call kmalloc(), and similarly kfree() for
dma_free?
I'd still like to see the uncached shadow stuff make a return one day,
it is an effective way of solving the problem, we'll just need to find a
cleaner way to implement it. A linear walk through the cache to
invalidate is so slow, it destroys any benefit gained from DMA in the
first place.
Cheers,
John
next prev parent reply other threads:[~2008-05-05 22:58 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-05 22:37 [PATCH] Microblaze: implement dma-coherent API and refactor cache flush code Stephen Neuendorffer
2008-05-05 22:37 ` Stephen Neuendorffer
2008-05-05 22:57 ` John Williams [this message]
2008-05-05 23:12 ` [PATCH] Microblaze: implement dma-coherent API and refactorcache " Stephen Neuendorffer
2008-05-06 0:14 ` John Williams
2008-05-06 0:31 ` [PATCH] Microblaze: implement dma-coherent API andrefactorcache " Stephen Neuendorffer
2008-05-06 7:23 ` Geert Uytterhoeven
2008-05-06 9:33 ` Michal Simek
2008-05-06 9:28 ` [PATCH] Microblaze: implement dma-coherent API and refactor cache " Michal Simek
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=1210028237.5798.121.camel@localhost \
--to=john.williams@petalogix.com \
--cc=arnd@arndb.de \
--cc=drepper@redhat.com \
--cc=grant.likely@secretlab.ca \
--cc=linnj@xilinx.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matthew@wil.cx \
--cc=microblaze-uclinux@itee.uq.edu.au \
--cc=monstr@monstr.eu \
--cc=stephen.neuendorffer@xilinx.com \
--cc=will.newton@gmail.com \
/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