linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
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 13:30:10 -0700	[thread overview]
Message-ID: <3A6C9852.4090201@valinux.com> (raw)
In-Reply-To: 3A6C8C6E.3C19F151@mvista.com


Dan Malek wrote:

> ...I don't know who wrote:
>
>>>> There is no pte table and so there is nothing mapped at that address,
>>>
>
> No, there is a pte table there, you just didn't get to printing
> anything from it......
>
> Roman Zipple wrote:
>
>> It depends what you what you want to do.
>
>
> I am really bad at guessing today....someone is going to have to
> tell me what you are trying to do.  From the few lines of code I have
> see posted, you are doing:
>
> 	1. Allocating some kernel virtual address and backing that
> 		with pages in real memory.
>
> 	2. Trying to find something in the kernel page tables, that I
> 		guessed wrong was a physical address of the pages.


Okay let me try and explain things a little better.

We need a virtually contiguous area of memory addressable by the
kernel.  We also need to know what physical pages actually make up this
virtually contiguous area.  Currently there is no kernel function to do
this explicitly (I'm probably going to add one to 2.5 for some other
work I'm doing though.)  So we call vmalloc_32 and get a virtual
address.  We then take that virtual address and grab the list pages that
the kernel just allocated.  We memset this full region in case these are
COW pages (shouldn't ever be COW pages on the Intel ia32, but perhaps on
other arch's.)  We get the list by walking the kernel page tables, as
you can see in the code snippet.

Later on this list of pages will be mapped into user space by the DRM's
mmap routine.  It uses vma_nopage to accomplish this.  vma_nopage
functions should return struct page *, we do this by returning
pagelist[page_offset_in_pages_from_start_of_vma].  This should work on
fine on any arch's kernel.  We haven't gotten to this point in the code
yet, so its not the issue we are addressing.

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.  We do virt_to_bus(pagelist[i]->virtual) to accomplish this
translation.  I assume this is what we would have to do on PPC to
program a device wanting u32 bus pointers on the PPC.  We aren't even
reaching that code yet, so its not the issue here.

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?  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?

Just FYI, the code I posted works fine on the ia32 platform (only tested
with the i386 classic 2-level page tables.)

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.)  I've
NEVER seen this in practice on an ia32 platform.  Does this happen only
happen on other platforms, or perhaps happen more often on other platforms?

-Jeff


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

  parent reply	other threads:[~2001-01-22 20:30 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 [this message]
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
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=3A6C9852.4090201@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 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).