From: Jeff Hartmann <jhartmann@valinux.com>
To: Dan Malek <dan@mvista.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 14:48:18 -0700 [thread overview]
Message-ID: <3A6CAAA2.6090607@valinux.com> (raw)
In-Reply-To: 3A6CA6A9.7794B603@mvista.com
Dan Malek wrote:
> 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?
Look at vread in vmalloc.c, I think it would handle holes in a
vmalloc'ed area (From a brief reading of the code.) I've seen postings
about this on linux-kernel. I don't see a vwrite implementation, but I
would assume you would have to do something similar for writes.
>
>
>> ..... 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).
I think it can, I've seen numerous people talk about it on
linux-kernel. I've also been told that my /dev/agpgart isn't 'safe'
because it assumes vmalloc'ed memory is always virtually contiguous. I
think this only happens when there isn't enough virtual address space in
the kernel and its fragmented (probably only happens on machines with
lots of memory.)
-Jeff
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2001-01-22 21:48 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
2001-01-22 21:48 ` Jeff Hartmann [this message]
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=3A6CAAA2.6090607@valinux.com \
--to=jhartmann@valinux.com \
--cc=benh@kernel.crashing.org \
--cc=dan@mvista.com \
--cc=dri-devel@lists.sourceforge.net \
--cc=gareth@valinux.com \
--cc=linuxppc-dev@lists.linuxppc.org \
--cc=michdaen@iiic.ethz.ch \
--cc=paulus@linuxcare.com \
--cc=zippel@fh-brandenburg.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.