linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Aaron Pace <kodiakuppercut@gmail.com>
To: Kumar Gala <galak@kernel.crashing.org>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: Non-contiguous physical memory
Date: Wed, 21 Jan 2009 11:00:58 -0700	[thread overview]
Message-ID: <bc81dc640901211000wc94dac3i802c8d6ae305d4a8@mail.gmail.com> (raw)
In-Reply-To: <3725D962-7F25-4A77-8D87-9BBA0A78D406@kernel.crashing.org>

>
> Its possible in that Linux supports this.  However the PPC32 code does not
> exist and would need to be added to support non-contiguous memory ranges.
>
> What exact PCI-E needs do you have?  Is PCI-E performance critical?  Is
> (are) your pci device(s) 64-bit address capable?
>
> I ask because depending on the answers doing straight 4G and PCI above that
> range might be sufficient for your needs.
>
> - k
>

Hello, thanks for responding.
The first take at this used your idea of mapping the PCI-E ranges
above the 4G boundary.
We have a localbus bridge device on the PCI-E bus that only supports
32-bit MMIO, but I believe we could satisfactorily work around that
problem using the ATMU registers.
However, one question that I had that I wasn't able to verify to my
satisfaction was whether I could ioremap a 36-bit physical address
when building for ppc32, as the PCI-E devices have memory ranges that
need to be accessible from userspace.  If that is possible, then this
may be the way to go, although it would still be nice not to lose the
128 meg for the localbus & CCSR region.

Thanks,
-Aaron

  reply	other threads:[~2009-01-21 18:01 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-21 15:18 Non-contiguous physical memory Aaron Pace
2009-01-21 17:28 ` Kumar Gala
2009-01-21 18:00   ` Aaron Pace [this message]
2009-01-21 23:25     ` Kumar Gala
2009-01-23 17:52   ` Michele Pallaro
2009-01-23 19:50     ` Kumar Gala

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=bc81dc640901211000wc94dac3i802c8d6ae305d4a8@mail.gmail.com \
    --to=kodiakuppercut@gmail.com \
    --cc=galak@kernel.crashing.org \
    --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).