From: Arjan van de Ven <arjanv@redhat.com>
To: linux-ia64@vger.kernel.org
Subject: [Linux-ia64] Re: [patch] support 64 bit pci_alloc_consistent
Date: Sun, 18 May 2003 09:29:02 +0000 [thread overview]
Message-ID: <marc-linux-ia64-105590723705930@msgid-missing> (raw)
In-Reply-To: <marc-linux-ia64-105590723705928@msgid-missing>
[-- Attachment #1: Type: text/plain, Size: 1857 bytes --]
On Sun, 2003-05-18 at 06:09, Jes Sorensen wrote:
> Hi Linus,
>
> This is patch which provides support for 64 bit address allocations from
> pci_alloc_consistent(), based on the address mask set through
> pci_set_consistent_dma_mask(). This is necessary on some platforms which
> are unable to provide physical memory in the lower 4GB block and do not
> provide IOMMU support for cards operating in certain bus modes, such as
> PCI-X on the SGI SN2.
I rather see a slightly different interface for this all together.
Right now the template for doing this is that the driver needs to check
the return value of the "set to 64 bit" operation and itself fall back
to 32 bit etc. What the driver really wants to achieve is to announce
device capabilities. The current interface is sort of also used to
retrieve the capability as well, which is a whole different thing.
An interface like
#define PCI_DMA_64BIT 0xffffffffffffffffULL
#define PCI_DMA_32BIT 0xffffffffULL
void pci_set_dma_capabilities(device,
u64 streaming_mask, u64 persistent_mask);
u64 pci_get_effective_streaming_mask(device);
u64 pci_get_effective_persistent_mask(device);
if for some reason the architecture PCI code needs or wants to reduce
the DMA mask (for example on non-PAE36 x86 kernels) it now doesn't need
to return failure for the 64 bit mask (and maybe even the 32 bit one)
but it can just do it. All places in drivers that actually care about
the resulting, effective DMA mask now have an interface to get this.
Why this interface? I think it fits closer to what drivers use it for;
uncomplicated announcing of the hardware's capabilities and independent
checking of the effective mask, for example for the decision about what
DMA descriptor model to use in some communications ringbuffer.
Greetings,
Arjan van de Ven
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2003-05-18 9:29 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-18 5:46 [Linux-ia64] Re: [patch] support 64 bit pci_alloc_consistent David S. Miller
2003-05-18 6:00 ` Andre Hedrick
2003-05-18 9:29 ` Arjan van de Ven [this message]
2003-05-18 9:35 ` David S. Miller
2003-05-18 9:43 ` Arjan van de Ven
2003-05-18 14:17 ` James Bottomley
2003-05-18 14:21 ` Arjan van de Ven
2003-05-18 14:28 ` James Bottomley
2003-05-18 17:22 ` 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
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-105590723705930@msgid-missing \
--to=arjanv@redhat.com \
--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