linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "David S. Miller" <davem@redhat.com>
To: Kanoj Sarcar <kanoj@google.engr.sgi.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:23:15 -0800 (PST)	[thread overview]
Message-ID: <14980.20915.447995.650580@pizda.ninka.net> (raw)
In-Reply-To: <200102092007.MAA70445@google.engr.sgi.com>

Kanoj Sarcar writes:
 > 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?

Only device code can determine if a device is A64 and will
actually spit out DAC addressing.

Let me give you one example.  On the Syskonnect Gigabit cards,
if any of the top 32-bits of an address are non-zero, DAC will
be used else a SAC cycle will be used for the address.

Alpha and Sparc64 PCI controllers interpret DAC and SAC addresses
differently.  For example, on sparc64, a DAC address to physical
memory should be formed by software with this equation:

	DAC_ADDR = (0x03fff00000000000 + PHYS_ADDR)

Alpha, if I remember correctly, uses a different upper constant.
For these two platforms, if SAC is used by the device then
normal IOMMU translation occurs (unless the IOMMU is disabled
thus putting the PCI controller into a bypass mode).

So it is not just "A64 capable", it is "will spit out DAC for
_this_ PCI dma address" and "can arch handle DACs appropriately."

You have to use a different type due to all of these variables.
So we will have dma64_addr_t and pci64_map_single et a.
The driver has to make a conscious decision to use 64-bit
DACs, and all devices I know of supporting DAC must be specifically
told to use DACs.  See things like SCSI_NCR_USE_64BIT_DAC in the
sym53c8xx driver.

The reason these interfaces don't and will not exist in 2.4.x is
precisely because I've had to track down and figure out all of these
arch and device specific details before deciding on an interface
that can work for everyone.  The PCI dma API in 2.4.x is frozen.

In short trying to get 64-bit DAC'able addresses with pci_map_single()
is illegal and any driver doing it is flat out non-portable.

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/

  reply	other threads:[~2001-02-09 20:23 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
2001-02-09 20:23       ` David S. Miller [this message]
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=14980.20915.447995.650580@pizda.ninka.net \
    --to=davem@redhat.com \
    --cc=grundler@cup.hp.com \
    --cc=kanoj@google.engr.sgi.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