All of lore.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 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.