public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Grant Grundler <iod00d@hp.com>
To: James Bottomley <James.Bottomley@SteelEye.com>
Cc: Arjan van de Ven <arjanv@redhat.com>,
	"David S. Miller" <davem@redhat.com>,
	Jes Sorensen <jes@wildopensource.com>,
	torvalds@transmeta.com, cngam@sgi.com, jeremy@sgi.com,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	linux-ia64@linuxia64.org, wildos@sgi.com
Subject: Re: [Linux-ia64] Re: [patch] support 64 bit pci_alloc_consistent
Date: Mon, 19 May 2003 09:26:48 -0700	[thread overview]
Message-ID: <20030519162648.GC21356@cup.hp.com> (raw)
In-Reply-To: <1053293187.10811.70.camel@mulgrave>

On Sun, May 18, 2003 at 04:26:22PM -0500, James Bottomley wrote:
> A full bit u64 mask should never fail...

OK. "never fail" in the sense that the driver has advertised a mask
which equals or exceeds the platform capabilities. 

Bottom line is the driver has to check the platform DMA support
likes the proposed mask and adjust it's behavior accordingly.
Existing API and Arjen's proposal both require that.

> Also, knowing the effective mask (and it would have to be set properly
> on return) would be extremely useful for drivers that have weird width
> modes (like aic with 64 vs 39 vs 32 bit addressing in the
> descriptors)

aic driver could try all three in order of preference?
"extremely useful" seems like a stretch to me.

> ...it would allow me to eliminate the memory size checks in
> those drivers.

I expect DMA support to determine how many bits are needed to
address all of physical RAM and accept/reject the 64/39/32-bit DMA
mask as appropriate. I haven't studied x86 DMA support recently.
There might be valid reasons it doesn't work that way.

grant

  reply	other threads:[~2003-05-19 16:13 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-18  4:09 [patch] support 64 bit pci_alloc_consistent Jes Sorensen
2003-05-18  5:46 ` David S. Miller
2003-05-18  6:00 ` Andre Hedrick
2003-05-18  9:29 ` Arjan van de Ven
2003-05-18  9:35   ` David S. Miller
2003-05-18  9:43     ` Arjan van de Ven
2003-05-18 17:22       ` [Linux-ia64] " Grant Grundler
2003-05-18 17:49         ` James Bottomley
2003-05-18 20:17           ` Grant Grundler
2003-05-18 21:26             ` James Bottomley
2003-05-19 16:26               ` Grant Grundler [this message]
2003-05-18 14:17   ` James Bottomley
2003-05-18 14:21     ` Arjan van de Ven
2003-05-18 14:28       ` James Bottomley

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=20030519162648.GC21356@cup.hp.com \
    --to=iod00d@hp.com \
    --cc=James.Bottomley@SteelEye.com \
    --cc=arjanv@redhat.com \
    --cc=cngam@sgi.com \
    --cc=davem@redhat.com \
    --cc=jeremy@sgi.com \
    --cc=jes@wildopensource.com \
    --cc=linux-ia64@linuxia64.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@transmeta.com \
    --cc=wildos@sgi.com \
    /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