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



  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