From: "David S. Miller" <davem@redhat.com>
To: linux-ia64@vger.kernel.org
Subject: [Linux-ia64] Re: PCI DAC routines for SN
Date: Wed, 24 Apr 2002 05:50:15 +0000 [thread overview]
Message-ID: <marc-linux-ia64-105590701905507@msgid-missing> (raw)
In-Reply-To: <marc-linux-ia64-105590701905493@msgid-missing>
From: Jesse Barnes <jbarnes@sgi.com>
Date: Tue, 23 Apr 2002 22:49:48 -0700
> Therefore pci_alloc_consistent MUST provide SAC only addressing.
>
> I was seeing patches where people would set the DMA mask for the
> pci_dev around pci_alloc_consistent calls in order to accomplish
> getting SAC addresses. That is exactly the kind of crap I was
> trying to avoid.
Why would they need to do that? If the driver sets its dma_mask to 64
bits, why can't the platform choose to return a 64 bit DMA address?
Obviously, if their device only supports 32 bits, then they'd set
their dma_mask accordingly and only get SAC addresses back from
alloc_consistent. I'm obviously not understaning something...
NO! They were doing this to workaround the IA64 broken behavior.
They wanted "dma_mask = DAC, but give me SAC for consistent
allocations" (ie. what the code should do automatically for them as
per Documentation/DMA-mapping.txt) and they were messing with the
dma_mask around the pci_alloc_consistent() calls because of IA64
not following the API.
> Is this needed because you bozos don't have any physical memory below
> 4GB on some weird ia64 system ___AND___ you lack a PCI IOMMU in the
> controllers again? This is getting rediculious if so, and I really
> want to avoid crapping up the PCI DMA interfaces just because the ia64
> PCI hardware folks keep making stupid design decisions.
Not at all. SGI Origin hardware has PCI bridges that can coherently
access 64 bit DMA regions. It can also map a limited number of 32 bit
addresses into arbitrary 4 GB memory windows of system memory. The
number of mappings is somewhat limited however, since most devices are
expected to use 64 bit addresses directly.
Bad expectation, most devices cannot do this. Like I suspected, bad
hardware design decisions are behind this.
I keep my position that there is no legitimate need to add this
interface besides perhaps broken hardware.
4GB of SAC addressible RAM is enough to satisfy even the most
convoluted use of consisten allocations.
Furthermore, and the important part you are ignoring, using DAC for
consistent allocations will incur a performance penalty because every
address cycle emitted by the device for a transaction will require
more cycles than if SAC addresses were only used for consistent
memory.
You have totally failed to consider this issue. All you can think
about is "my system can do it, why can't I have the interface" without
once considering if that interface makes any sense to use at all even
if you can do it.
next prev parent reply other threads:[~2002-04-24 5:50 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-22 22:34 [Linux-ia64] Re: PCI DAC routines for SN David Mosberger
2002-04-22 22:39 ` Jesse Barnes
2002-04-22 23:07 ` David Mosberger
2002-04-22 23:40 ` Jesse Barnes
2002-04-23 1:34 ` Grant Grundler
2002-04-23 21:11 ` Grant Grundler
2002-04-24 4:04 ` David S. Miller
2002-04-24 5:49 ` Jesse Barnes
2002-04-24 5:50 ` David S. Miller [this message]
2002-04-24 16:13 ` Grant Grundler
2002-04-24 17:39 ` David S. Miller
2002-04-24 17:40 ` David S. Miller
2002-04-24 19:45 ` Jesse Barnes
2002-04-24 23:13 ` Jesse Barnes
2002-04-24 23:53 ` David S. Miller
2002-04-25 0:08 ` David S. Miller
2002-04-25 0:11 ` Jesse Barnes
2002-04-25 0:17 ` David S. Miller
2002-04-25 0:21 ` Jesse Barnes
2002-04-25 0:36 ` Jesse Barnes
2002-04-25 0:43 ` David S. Miller
2002-04-25 1:00 ` David S. Miller
2002-04-25 1:01 ` Jesse Barnes
2002-04-25 1:22 ` Jesse Barnes
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=marc-linux-ia64-105590701905507@msgid-missing \
--to=davem@redhat.com \
--cc=linux-ia64@vger.kernel.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