From: Dan Malek <dan@mvista•com>
To: Jeff Hartmann <jhartmann@valinux•com>
Cc: Roman Zippel <zippel@fh-brandenburg•de>,
michdaen@iiic•ethz.ch,
Benjamin Herrenschmidt <benh@kernel•crashing.org>,
Gareth Hughes <gareth@valinux•com>,
linuxppc-dev@lists•linuxppc.org, dri-devel@lists•sourceforge.net,
Paul Mackerras <paulus@linuxcare•com>
Subject: Re: [Dri-devel] PPC Lockup (ati-pcigart-branch)
Date: Mon, 22 Jan 2001 16:31:21 -0500 [thread overview]
Message-ID: <3A6CA6A9.7794B603@mvista.com> (raw)
In-Reply-To: 3A6C9852.4090201@valinux.com
Jeff Hartmann wrote:
> Okay let me try and explain things a little better.
Got it. That is what I was guessing, only surprised you are holding
page structs, but that makes sense.
> ...... Currently there is no kernel function to do
> this explicitly
I'm working on that. The PowerPC port cheated by using BATs and
trivial macros, but this doesn't work on some of the newer processors
and more complex applications. Other architectures did the same, and
I am surprised there aren't generic kernel functions to track down this
information. In fact, these functions are already present for 4xx and
8xx processors, so don't write anything new.
> Another thing that happens later is that we need the bus address of each
> of these pages to program the card to do scatter gather dma from this
> region.
That's where this is going to fall apart on PowerPC.
> ..... We do virt_to_bus(pagelist[i]->virtual) to accomplish this
> translation.
I have to write some code (or actually remove some #ifdefs) before
this will work for you.
> I know on the ia32 a pgd/pmd can actually point to 4MB pages rather then
> a real pte. Does the PowerPC have anything like this?
Not yet. It's on the way....
> .... I would doubt
> that I would encounter anything like this from a vmalloc'ed area of
> memory (since vmalloc is arch independent and it would call alloc_page
> for each individual pte.) Am I correct in this assumption?
Yes.
> Just FYI, the code I posted works fine on the ia32 platform (only tested
> with the i386 classic 2-level page tables.)
What you are doing so far should work too on PowerPC.
> Another thing we might be running into here is that vmalloc does not
> guarantee a virtually contiguous area of memory (or so I am told.)
Ummm...of course it is virtually contiguous. How could it be
different? You request a size, and it returns a base virtual address.
If there were holes in it, how would you know?
> ..... I've
> NEVER seen this in practice on an ia32 platform.
It can't happen on any platform (or I don't understand something about
the comment, which could very well be the case today).
-- Dan
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2001-01-22 21:31 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-01-19 3:26 PPC Lockup (ati-pcigart-branch) Michel Dänzer
2001-01-19 3:55 ` Dan Malek
2001-01-19 6:53 ` [Dri-devel] " Gareth Hughes
2001-01-19 16:48 ` Jeff Hartmann
2001-01-19 17:24 ` Dan Malek
2001-01-20 0:45 ` Gareth Hughes
2001-01-19 16:40 ` [Dri-devel] " Jeff Hartmann
2001-01-19 17:11 ` Benjamin Herrenschmidt
2001-01-19 22:26 ` Chris Emerson
2001-01-19 22:59 ` Benjamin Herrenschmidt
2001-01-19 23:43 ` Chris Emerson
2001-01-20 1:38 ` Benjamin Herrenschmidt
2001-01-20 13:21 ` Michael Schmitz
2001-01-20 16:00 ` Benjamin Herrenschmidt
2001-01-20 17:03 ` Michael Schmitz
2001-01-20 2:46 ` Michel Dänzer
2001-01-20 4:17 ` Michel Dänzer
2001-01-22 9:44 ` Michel Dänzer
2001-01-22 17:59 ` Roman Zippel
2001-01-22 18:18 ` Michel Dänzer
2001-01-22 18:54 ` Roman Zippel
2001-01-22 19:39 ` Dan Malek
2001-01-22 20:08 ` Michel Dänzer
2001-01-22 20:30 ` Jeff Hartmann
2001-01-22 21:23 ` Roman Zippel
2001-01-22 23:12 ` Frank Rowand
2001-01-22 21:31 ` Dan Malek [this message]
2001-01-22 21:48 ` Jeff Hartmann
2001-01-22 22:15 ` Roman Zippel
2001-01-23 16:14 ` Mike Beede
2001-01-22 22:31 ` Roman Zippel
2001-01-23 0:24 ` Dan Malek
2001-01-23 2:28 ` Takashi Oe
2001-01-23 2:40 ` Dan Malek
2001-01-23 4:40 ` Ralph Metzler
2001-01-23 5:48 ` Takashi Oe
2001-01-23 11:24 ` Roman Zippel
2001-01-23 0:34 ` Frank Rowand
2001-01-23 0:43 ` Frank Rowand
2001-01-23 11:32 ` Roman Zippel
2001-01-22 20:43 ` Roman Zippel
2001-01-22 21:07 ` Jeff Hartmann
2001-01-22 17:33 ` Dan Malek
2001-01-22 17:38 ` Jeff Hartmann
2001-01-22 17:38 ` Gareth Hughes
2001-01-22 17:43 ` Michel Dänzer
2001-01-22 18:36 ` Dan Malek
2001-01-22 18:44 ` Jeff Hartmann
2001-01-22 18:47 ` Michel Dänzer
2001-01-22 21:13 ` Dan Malek
2001-01-22 21:58 ` Roman Zippel
2001-01-22 23:48 ` Paul Mackerras
2001-01-23 0:13 ` Dan Malek
2001-01-20 13:15 ` Michael Schmitz
2001-01-19 17:11 ` Wolfgang Denk
-- strict thread matches above, loose matches on Subject: below --
2001-01-23 3:34 Iain Sandoe
2001-01-23 6:49 Robert E Brose II
2001-01-23 7:01 ` Geert Uytterhoeven
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=3A6CA6A9.7794B603@mvista.com \
--to=dan@mvista$(echo .)com \
--cc=benh@kernel$(echo .)crashing.org \
--cc=dri-devel@lists$(echo .)sourceforge.net \
--cc=gareth@valinux$(echo .)com \
--cc=jhartmann@valinux$(echo .)com \
--cc=linuxppc-dev@lists$(echo .)linuxppc.org \
--cc=michdaen@iiic$(echo .)ethz.ch \
--cc=paulus@linuxcare$(echo .)com \
--cc=zippel@fh-brandenburg$(echo .)de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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