public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
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.


  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