All of lore.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 04:04:10 +0000	[thread overview]
Message-ID: <marc-linux-ia64-105590701905503@msgid-missing> (raw)
In-Reply-To: <marc-linux-ia64-105590701905493@msgid-missing>

   From: Jesse Barnes <jbarnes@sgi.com>
   Date: Mon, 22 Apr 2002 16:40:14 -0700

   On Mon, Apr 22, 2002 at 04:07:33PM -0700, David Mosberger wrote:
   > Oh man, what a mess!  Have you checked with Dave Miller?  I suspect
   > he might not like this.  I'm not terribly fond of it either as it
   
   He was the one that implemented it I thought.  His assertion was that
   since most chipsets don't handle 64 bit coherent allocations well, the
   consistent interface should be forced to return a 32 bit address (is
   that right Dave?).  I don't mind that as long as we add a DAC
   consistent call, otherwise I'd like to leave it up to the platform
   (i.e. ia64/sn could return a 64 bit address and sparc64 could do 32).
   
%99 of PCI chips out there do not support DAC addressing for things
like descriptor tables etc.  So it's not a matter of "well" it's
a matter of "at all".

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.

Therefore, as per the API specification
(Documentation/DMA-mapping.txt) and reality, it's unacceptable
for pci_alloc_consistent() to return anything other than SAC
addresses (or something more constrained, if the DMA mask indicates
this, for example for devices with ISA addressing limitations).

I think it is unreasonable to add a special DAC alloc consistent
call.

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.


  parent reply	other threads:[~2002-04-24  4:04 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 [this message]
2002-04-24  5:49 ` Jesse Barnes
2002-04-24  5:50 ` David S. Miller
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-105590701905503@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.