From: Terence Ripperda <tripperda@nvidia.com>
To: Jesse Barnes <jbarnes@engr.sgi.com>
Cc: arjanv@redhat.com, Andi Kleen <ak@muc.de>,
Terence Ripperda <tripperda@nvidia.com>,
discuss@x86-64.org, tiwai@suse.de, linux-kernel@vger.kernel.org
Subject: Re: 32-bit dma allocations on 64-bit platforms
Date: Thu, 24 Jun 2004 09:39:27 -0500 [thread overview]
Message-ID: <20040624143927.GH983@hygelac> (raw)
In-Reply-To: <200406240948.07234.jbarnes@engr.sgi.com>
correct. I checked with my contacts here on the PCI express requirements.
Apparently the spec says "A PCI Express Endpoint operating as the
Requester of a Memory Transaction is required to be capable of
generating addresses greater than 4GB", but my contact claims this is a
"soft" requirement.
but even if all PCI-X and PCI-E devices properly addressed the full
64-bits, legacy 32-bit PCI devices can be plugged into the motherboards as
well. my Intel em64t boards have mostly PCI-X, but 1 PCI slot and my amd
x86_64 have all PCI slots (aside from the main PCI-E slot).
also, at least one motherboard manufacturer claims PCI-E + AGP, but the AGP
is really just an AGP form-factor slot on the PCI bus.
Thanks,
Terence
On Thu, Jun 24, 2004 at 06:48:07AM -0700, jbarnes@engr.sgi.com wrote:
> On Thursday, June 24, 2004 2:18 am, Arjan van de Ven wrote:
> > What is the problem again, can't the driver us the dynamic pci mapping
> > API which does allow more memory to be mapped even on crippled
> machines
> > without iommu ?
> > And isn't this a problem that will vanish since PCI Express and PCI X
> > both *require* support for 64 bit addressing, so all higher speed
> cards
> > are going to be ok in principle ?
>
> Well, PCI-X may require it, but there certainly are PCI-X devices that
> don't
> do 64 bit addressing, or if they do, it's a crippled implementation
> (e.g. top
> 32 bits have to be constant).
>
> Jesse
next prev parent reply other threads:[~2004-06-24 14:42 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <2akPm-16l-65@gated-at.bofh.it>
2004-06-23 21:46 ` 32-bit dma allocations on 64-bit platforms Andi Kleen
2004-06-24 6:18 ` Arjan van de Ven
2004-06-24 10:33 ` Andi Kleen
2004-06-24 13:48 ` Jesse Barnes
2004-06-24 14:39 ` Terence Ripperda [this message]
2004-06-24 15:01 ` [discuss] " Andi Kleen
[not found] <m3acyu6pwd.fsf@averell.firstfloor.org>
[not found] ` <20040623213643.GB32456@hygelac>
2004-06-23 23:46 ` Andi Kleen
2004-06-24 11:13 ` Takashi Iwai
2004-06-24 14:45 ` Terence Ripperda
2004-06-24 15:41 ` Andrea Arcangeli
2004-06-24 15:44 ` Terence Ripperda
2004-06-24 18:51 ` Andi Kleen
2004-06-26 4:58 ` David Mosberger
2004-06-23 18:35 Terence Ripperda
2004-06-23 19:19 ` Jeff Garzik
2004-06-26 5:05 ` David Mosberger
2004-06-26 7:16 ` Arjan van de Ven
2004-06-29 6:13 ` David Mosberger
2004-06-29 6:55 ` Arjan van de Ven
2004-06-30 8:00 ` Jes Sorensen
2004-06-26 5:02 ` David Mosberger
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=20040624143927.GH983@hygelac \
--to=tripperda@nvidia.com \
--cc=ak@muc.de \
--cc=arjanv@redhat.com \
--cc=discuss@x86-64.org \
--cc=jbarnes@engr.sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tiwai@suse.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