From: David Gibson <david@gibson.dropbear.id.au>
To: linuxppc-embedded@lists.linuxppc.org
Subject: Re: Workaround for USB DMA bugs
Date: Thu, 4 Apr 2002 15:23:49 +1000 [thread overview]
Message-ID: <20020404052349.GN21034@zax> (raw)
In-Reply-To: <3CABD1E0.7020008@embeddededge.com>
On Wed, Apr 03, 2002 at 11:09:04PM -0500, Dan Malek wrote:
>
> David Gibson wrote:
>
> >Oh, right, yes. That was actually what I was meaning when I said
> >"aligned" (sort of aligned at both ends), forgetting that the normal
> >meaning only applies to the start address.
>
> I guess if we can ensure a DMA-only pool, simple alignment will work.
> You just can't kmalloc() because you don't know what may follow something
> that isn't modulo cache line size. You also have to be careful of code
> that allocates a large object, then uses part of it for DMA and other
> parts for processor core data. I'm not sure we want to require kmalloc()
> to always cache align due to the potential for wasted memory space.
kmalloc() already guarantess cacheline alignment (at the beginning).
Which means it is safe as long as the allocation is a multiple of the
cacheline size (which comes for free on allocations of a largish power
of 2, a common case).
Possibly a better approach would be to make the consistent_sync()
function be more careful and flush rather than invalidate cachelines
which are only partially covered by the region given. At the moment
it invalidates everything and hence is only safe for regions which are
cacheline aligned, and of size a multiple of cacheline size.
--
David Gibson | For every complex problem there is a
david@gibson.dropbear.id.au | solution which is simple, neat and
| wrong. -- H.L. Mencken
http://www.ozlabs.org/people/dgibson
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2002-04-04 5:23 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-03 2:43 Workaround for USB DMA bugs David Gibson
2002-04-03 8:17 ` Armin
2002-04-03 17:39 ` Frank Rowand
2002-04-03 17:49 ` Dan Malek
2002-04-03 20:43 ` David Blythe
2002-04-03 23:34 ` David Gibson
2002-04-03 9:45 ` "David Müller (ELSOFT AG)"
2002-04-03 23:35 ` David Gibson
2002-04-03 17:42 ` Dan Malek
2002-04-03 23:40 ` David Gibson
2002-04-04 2:54 ` Dan Malek
2002-04-04 3:48 ` David Gibson
2002-04-04 4:09 ` Dan Malek
2002-04-04 5:23 ` David Gibson [this message]
2002-04-04 6:08 ` Dan Malek
2002-04-04 6:30 ` David Gibson
2002-04-04 20:21 ` David Blythe
2002-04-04 12:35 ` Brad Parker
2002-04-04 14:12 ` Dan Malek
-- strict thread matches above, loose matches on Subject: below --
2002-04-04 4:19 Jeremy Rosen
2002-04-04 6:16 ` Dan Malek
2002-04-04 6:32 ` David Gibson
2002-04-04 6:40 Rosen Jeremy
2002-04-04 6:52 ` David Gibson
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=20020404052349.GN21034@zax \
--to=david@gibson.dropbear.id.au \
--cc=linuxppc-embedded@lists.linuxppc.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).