From: "Gérard Roudier" <groudier@free.fr>
To: linux-ia64@vger.kernel.org
Subject: Re: [Linux-ia64] 2.4.16-ia64-011128 is missing dma64_addr_t
Date: Tue, 04 Dec 2001 19:38:24 +0000 [thread overview]
Message-ID: <marc-linux-ia64-105590698805612@msgid-missing> (raw)
In-Reply-To: <marc-linux-ia64-105590698805568@msgid-missing>
On Tue, 4 Dec 2001, David Mosberger wrote:
> >>>>> On Tue, 4 Dec 2001 19:15:06 +0100 (CET), =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@free.fr> said:
>
> Gerard> I am under the impression that it has been invented for
> Gerard> sparc64 as a provision for PCI devices that may gain
> Gerard> advantage of real 64 bit DMA PCI on this hardware. This
> Gerard> platform has some streaming mode DMA implemented for 32 bit
> Gerard> PCI through an IO/MMU.
>
> Gerard> Choices are:
>
> Gerard> 1) Faster IOs but only in 32 bit PCI mode + software
> Gerard> complexity as a malus. 2) Slower IOs in 64 bit PCI mode.
>
> Gerard> Chosing the less bad one, here choice #1, is what is to be
> Gerard> done when no good choice is available.
>
> Close, but not quite: DaveM *always* wants to use SAC on SPARC64
> (using the I/O TLB if necessary) *unless* the device creates so many
> mappings that it could exhaust the address space of the I/O TLB. His
> choice is motivated by the assumption that DAC is slower than SAC. I
DAC costs 1 additionnal PCI cycle more than SAC for each transaction.
Given reasonnable burst lengths you will not see significant differences
all other things being equal, but they aren't on sparc64.
> don't believe that's a significant effect for machines with real
> 64-bit PCI buses. Also, I think for most device driver writers, the
> complexity of having to choose between pci_* and pci_dac_* is just too
> much (just look at the original qlogic drivers if you don't know what
> I mean...).
I can guess.
> So, the rule of thumb should be:
>
> (1) use the normal pci_* routines.
>
> (2) if the device is DAC capable and can *truly* address all 64-bit
> address bits (not just 36 bits or whatever) and SPARC64 runs into
> I/O TLB address space trouble, consider using pci_dac_*.
I am rather interested in practice here and the pci_dac_* stuff seems to
address sparc64 only (and only linux, btw). Nothing than can motivate
anybody excepted DSM, in my opinion. :-)
Gérard.
next prev parent reply other threads:[~2001-12-04 19:38 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-12-02 3:56 [Linux-ia64] 2.4.16-ia64-011128 is missing dma64_addr_t Keith Owens
2001-12-03 18:23 ` Gérard Roudier
2001-12-03 19:34 ` David Mosberger
2001-12-03 21:29 ` David Mosberger
2001-12-04 17:01 ` Gérard Roudier
2001-12-04 18:15 ` Gérard Roudier
2001-12-04 19:38 ` Gérard Roudier [this message]
2001-12-04 19:54 ` David Mosberger
2001-12-04 19:54 ` David Mosberger
2001-12-04 19:54 ` David Mosberger
2001-12-04 19:55 ` David Mosberger
2001-12-04 19:56 ` David Mosberger
2001-12-04 21:42 ` David Mosberger
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-105590698805612@msgid-missing \
--to=groudier@free.fr \
--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