From: Paul Mackerras <paulus@au1.ibm.com>
To: Matt Porter <porter@cox.net>
Cc: Dan Malek <dan@embeddededge.com>,
Joakim Tjernlund <joakim.tjernlund@lumentis.se>,
Pantelis Antoniou <panto@intracom.gr>,
linuxppc-embedded@lists.linuxppc.org
Subject: Re: Regarding consistent_alloc
Date: Sat, 7 Dec 2002 11:25:26 +1100 [thread overview]
Message-ID: <15857.16374.833902.735605@argo.ozlabs.ibm.com> (raw)
In-Reply-To: <20021206112901.A18257@home.com>
Matt Porter writes:
> On Fri, Dec 06, 2002 at 11:56:22AM -0500, Dan Malek wrote:
> > Matt Porter wrote:
> >
> > > .... If you
> > > want the kernel virtual address then you can apply __va to that.
> >
> > Errr....no, you can't. That would give you the cached mapping.
> > You need to hang on to both the dma_handle (the phys address token)
> > and the virtual address returned by the function. That's why both
> > are returned.
>
> That's what I said...but you clipped it out. Once again,
> consistent_alloc provides the caller everything they need.
> An uncached mapping, a phys address, and from that you can use
> __va() to get the cached mapping.
Matt, you know this I'm sure, but other people reading this might not:
You should NOT use the cached mapping unless you really know *exactly*
what you are doing.
The PowerPC architecture specifies that accessing a given physical
address through an uncached mapping, when there exists a copy of that
physical location in cache, is a programming error. Different
implementations will do different things in this case.
> Seemed clear enough to me the first time. My definition of a
> "kernel virtual address" is the lowmem cached mapping. If
> I meant the uncached mapping I would have said it was a "kernel
> vmalloc address" or something. :)
A "kernel virtual address" is, to me (and to Dan as well, I expect),
any virtual address in the kernel portion of the address space
(i.e. above TASK_SIZE). (Of course, you are free to adopt Humpty
Dumpty's attitude in Through the Looking Glass: "'When I use a word,
Humpty Dumpty said in rather a scornful tone, 'it means just what I
choose it to mean - neither more nor less.'" ;-)
Regards,
Paul.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2002-12-07 0:25 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-06 13:18 Regarding consistent_alloc Pantelis Antoniou
2002-12-06 13:23 ` Pantelis Antoniou
2002-12-06 14:25 ` Joakim Tjernlund
2002-12-06 15:59 ` Matt Porter
2002-12-06 16:08 ` Joakim Tjernlund
2002-12-06 18:30 ` Matt Porter
2002-12-06 18:15 ` Joakim Tjernlund
2002-12-06 18:52 ` Matt Porter
2002-12-06 19:59 ` Dan Malek
2002-12-06 22:11 ` Joakim Tjernlund
2002-12-07 0:16 ` Paul Mackerras
2002-12-07 12:53 ` Joakim Tjernlund
2002-12-07 16:53 ` Dan Malek
2002-12-09 9:06 ` Pantelis Antoniou
2002-12-10 17:49 ` Tom Rini
2002-12-11 3:52 ` acurtis
2002-12-11 8:57 ` Joakim Tjernlund
2002-12-11 9:58 ` Pantelis Antoniou
2002-12-11 14:41 ` acurtis
2002-12-11 15:01 ` Pantelis Antoniou
2002-12-11 15:36 ` acurtis
2002-12-12 3:32 ` Dan Malek
2002-12-11 14:56 ` Tom Rini
2002-12-11 15:07 ` Pantelis Antoniou
2002-12-12 3:41 ` Dan Malek
2002-12-12 8:00 ` Pantelis Antoniou
2002-12-12 8:18 ` Wolfgang Denk
2002-12-12 8:37 ` Pantelis Antoniou
2002-12-12 12:56 ` Is the preemptive kernel patch unsafe for 8xx/PPC? Joakim Tjernlund
2002-12-12 18:28 ` Eugene Surovegin
2002-12-12 20:35 ` Joakim Tjernlund
2002-12-13 4:12 ` acurtis
2002-12-13 6:09 ` Eugene Surovegin
2002-12-13 7:47 ` Joakim Tjernlund
2002-12-16 14:41 ` acurtis
2002-12-13 4:08 ` acurtis
2002-12-12 16:53 ` "Missing" patches (Was: Re: Regarding consistent_alloc) Tom Rini
2002-12-06 16:56 ` Regarding consistent_alloc Dan Malek
2002-12-06 18:29 ` Matt Porter
2002-12-06 19:45 ` Dan Malek
2002-12-07 0:25 ` Paul Mackerras [this message]
2002-12-06 15:54 ` Matt Porter
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=15857.16374.833902.735605@argo.ozlabs.ibm.com \
--to=paulus@au1.ibm.com \
--cc=dan@embeddededge.com \
--cc=joakim.tjernlund@lumentis.se \
--cc=linuxppc-embedded@lists.linuxppc.org \
--cc=panto@intracom.gr \
--cc=porter@cox.net \
/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).