From: Kanoj Sarcar <kanoj@google.engr.sgi.com>
To: "David S. Miller" <davem@redhat.com>
Cc: Grant Grundler <grundler@cup.hp.com>, linux-mm@kvack.org
Subject: Re: IOMMU setup vs DAC (PCI)
Date: Fri, 9 Feb 2001 12:07:09 -0800 (PST) [thread overview]
Message-ID: <200102092007.MAA70445@google.engr.sgi.com> (raw)
In-Reply-To: <14980.19083.144384.865666@pizda.ninka.net> from "David S. Miller" at Feb 09, 2001 11:52:43 AM
>
>
> Kanoj Sarcar writes:
> > dma_addr_t should be unsigned long, which is 64 bits on 64 bit
> > architectures, so things are fine there.
> >
> > On regular x86, dma_addr_t is u32, which still works.
>
> It's 32-bit on sparc64 since 32-bit DMA addresses are all
> we need since the IOMMU is used for anything.
Ok.
>
> In fact, if your architecture is doing nothing other
> than PCI, you _OUGHT_ to make it 32-bit even on 64-bit
> platforms because the PCI dma interface does not support
> 64-bit DACs in any way shape or form until 2.5.x in then
> a new dma64_addr_t type will be used to denote a DAC
> address.
Way I look at it, if you have a 64 bit platform which has
hardware to send PCI64 data to any piece of memory, then
it would be sad if software were to limit you and say "No,
PCI64 dma data must go within this piece of (low) memory
which the kernel can address with 32 bits". Because, this
assumes usage of bounce buffers, which is not pretty
performance wise.
In some cases (in 2.4, prior to dma64_addr_t), if arch
code can figure out a device is A64, the driver does support
A64, then it can privately decide to use A64 style mapping
and pci_dma operations for that pci_dev. Is there a problem
with this approach?
Kanoj
>
> Later,
> David S. Miller
> davem@redhat.com
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
next prev parent reply other threads:[~2001-02-09 20:07 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-02-09 19:39 Grant Grundler
2001-02-09 19:42 ` David S. Miller
2001-02-09 20:04 ` Grant Grundler
2001-02-09 19:47 ` Kanoj Sarcar
2001-02-09 19:52 ` David S. Miller
2001-02-09 20:07 ` Kanoj Sarcar [this message]
2001-02-09 20:23 ` David S. Miller
2001-02-09 21:11 ` Kanoj Sarcar
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=200102092007.MAA70445@google.engr.sgi.com \
--to=kanoj@google.engr.sgi.com \
--cc=davem@redhat.com \
--cc=grundler@cup.hp.com \
--cc=linux-mm@kvack.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