linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: jbahr <jbahr@set-software-services.com>
To: linuxppc-dev@ozlabs.org
Subject: Discontiguous Memory
Date: Fri, 15 Sep 2006 13:22:48 -0700 (PDT)	[thread overview]
Message-ID: <6332580.post@talk.nabble.com> (raw)


We have a client building a PPC8548-based product who insists that we
allocate DRAM real address space in two large chunks at 0-2GB and 4-6GB in
the 36-bit address space.  It doesn't look like U-Boot's bd_info structure
allows for that, and it doesn't look like the Linux init routines (which
accesses the passed table) knows how to handle discontiguous memory either
(as opposed to X86 Linux, which can accept an E820 table). 

It looks like Linux cleans out the TLB's pretty quickly, so it wouldn't know
the VA-to-RA mapping.   

I've seen papers on some PPC Linuxes that handle large discontiguous real
DRAM memory spaces, but it doesn't look like the Linux in ELDK does.  Is
that correct? 

This is just the start of a headache between the architects and we poor
implementers.  It's not clear to us that, even with ATMU support, how normal
drivers are going to know how to create real addresses for buffers and such
to use when programming DMA controllers or external PCI devices. 

Are this really a problem or is there kernel provision for the PPC for
discontiguous real memory DRAM space?

Any comments would be VERY appreciated. 

Regards, 
J
-- 
View this message in context: http://www.nabble.com/Discontiguous-Memory-tf2279691.html#a6332580
Sent from the linuxppc-dev forum at Nabble.com.

             reply	other threads:[~2006-09-15 20:40 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-15 20:22 jbahr [this message]
2006-09-15 23:24 ` Discontiguous Memory Arnd Bergmann
2006-09-15 23:31   ` Jeffery Bahr
2006-09-16  0:56 ` Benjamin Herrenschmidt
2006-09-16  9:51   ` Arnd Bergmann
2006-09-16 22:50     ` Benjamin Herrenschmidt

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=6332580.post@talk.nabble.com \
    --to=jbahr@set-software-services.com \
    --cc=linuxppc-dev@ozlabs.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).