From: Krzysztof Halasa <khc@pm.waw.pl>
To: "David S. Miller" <davem@redhat.com>
Cc: alan@lxorguk.ukuu.org.uk, jes@trained-monkey.org,
zaitcev@redhat.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] RFC: kills consistent_dma_mask
Date: 01 Sep 2003 19:14:46 +0200 [thread overview]
Message-ID: <m3ptikctx5.fsf@defiant.pm.waw.pl> (raw)
In-Reply-To: <20030901004308.477f8cc8.davem@redhat.com>
"David S. Miller" <davem@redhat.com> writes:
> Sure, I'm fine with this as a termporary thing until we
> work out the details properly.
How about the following patch? It corrects most, if not all, obvious
things.
--- linux-2.6/Documentation/DMA-mapping.txt 2003-08-09 06:36:56.000000000 +0200
+++ linux-2.6/Documentation/DMA-mapping.txt.orig 2003-09-01 19:06:16.000000000 +0200
@@ -76,7 +76,8 @@
Does your device have any DMA addressing limitations? For example, is
your device only capable of driving the low order 24-bits of address
on the PCI bus for SAC DMA transfers? If so, you need to inform the
-PCI layer of this fact.
+PCI layer of this fact. Even if you do, this information will be
+ignored on some architectures, such as i386.
By default, the kernel assumes that your device can address the full
32-bits in a SAC cycle. For a 64-bit DAC capable device, this needs
@@ -123,6 +124,11 @@
2) Use some non-DMA mode for data transfer, if possible.
3) Ignore this device and do not initialize it.
+Most platforms will ignore pci_set_consistent_dma_mask() at all and, for
+example, use the device mask set with pci_set_dma_mask() for consistent
+allocations. Remember that even setting both masks to the same value
+doesn't necessarily mean this value will actually be honoured.
+
It is recommended that your driver print a kernel KERN_WARNING message
when you end up performing either #2 or #3. In this manner, if a user
of your driver reports that performance is bad or that the device is not
@@ -180,10 +186,8 @@
goto ignore_this_device;
}
-pci_set_consistent_dma_mask() will always be able to set the same or a
-smaller mask as pci_set_dma_mask(). However for the rare case that a
-device driver only uses consistent allocations, one would have to
-check the return value from pci_set_consistent_dma_mask().
+For the rare case that a device driver only uses consistent allocations,
+one would have to check the return value from pci_set_consistent_dma_mask().
If your 64-bit device is going to be an enormous consumer of DMA
mappings, this can be problematic since the DMA mappings are a
@@ -201,17 +205,17 @@
}
When pci_set_dma_mask() is successful, and returns zero, the PCI layer
-saves away this mask you have provided. The PCI layer will use this
-information later when you make DMA mappings.
+saves away this mask you have provided. The PCI layer may or may not
+use this information later when you make DMA mappings.
There is a case which we are aware of at this time, which is worth
mentioning in this documentation. If your device supports multiple
functions (for example a sound card provides playback and record
functions) and the various different functions have _different_
DMA addressing limitations, you may wish to probe each mask and
-only provide the functionality which the machine can handle. It
-is important that the last call to pci_set_dma_mask() be for the
-most specific mask.
+only provide the functionality which the machine can handle. Remember
+that the last call to pci_set_dma_mask() will set the mask which will
+(or will not) be used for subsequent DMA mapping requests.
Here is pseudo-code showing how this might be done:
@@ -239,7 +243,10 @@
A sound card was used as an example here because this genre of PCI
devices seems to be littered with ISA chips given a PCI front end,
-and thus retaining the 16MB DMA addressing limitations of ISA.
+and thus retaining the 16MB DMA addressing limitations of ISA. While
+this example will not probably work for pci_map_* functions, the mask
+will be honoured for pci_alloc_consistent() on all platforms except
+ia64 and x86-64.
Types of DMA mappings
@@ -330,10 +337,10 @@
default return a DMA address which is SAC (Single Address Cycle)
addressable. Even if the device indicates (via PCI dma mask) that it
may address the upper 32-bits and thus perform DAC cycles, consistent
-allocation will only return > 32-bit PCI addresses for DMA if the
-consistent dma mask has been explicitly changed via
+allocation on ia64 and x86-64 will only return > 32-bit PCI addresses
+for DMA if the consistent dma mask has been explicitly changed via
pci_set_consistent_dma_mask(). This is true of the pci_pool interface
-as well.
+as well. On other platforms, use pci_set_dma_mask().
pci_alloc_consistent returns two values: the virtual address which you
can use to access it from the CPU and dma_handle which you pass to the
--
Krzysztof Halasa, B*FH
next prev parent reply other threads:[~2003-09-01 17:15 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-17 22:34 [PATCH] RFC: kills consistent_dma_mask Krzysztof Halasa
2003-08-18 6:37 ` David S. Miller
2003-08-18 12:44 ` Krzysztof Halasa
2003-08-18 12:43 ` David S. Miller
2003-08-18 15:54 ` Krzysztof Halasa
2003-08-18 16:49 ` David S. Miller
2003-08-18 18:21 ` Krzysztof Halasa
2003-08-18 18:50 ` David S. Miller
2003-08-18 21:58 ` Krzysztof Halasa
2003-08-19 9:24 ` Jes Sorensen
2003-08-19 9:21 ` Jes Sorensen
2003-08-18 13:00 ` Jes Sorensen
2003-08-18 8:07 ` Christoph Hellwig
2003-08-18 15:15 ` Pete Zaitcev
2003-08-18 16:14 ` Krzysztof Halasa
2003-08-19 9:16 ` Jes Sorensen
2003-08-19 9:49 ` Krzysztof Halasa
2003-08-19 10:15 ` Jes Sorensen
2003-08-19 9:03 ` Jes Sorensen
2003-08-19 13:07 ` Alan Cox
2003-08-19 13:20 ` Jes Sorensen
2003-08-19 16:55 ` David S. Miller
2003-08-19 18:33 ` Alan Cox
2003-08-19 18:31 ` David S. Miller
2003-08-19 20:31 ` Krzysztof Halasa
2003-08-22 11:54 ` Krzysztof Halasa
2003-08-23 17:11 ` Jes Sorensen
2003-08-24 12:06 ` Krzysztof Halasa
2003-08-24 13:00 ` David S. Miller
2003-08-24 19:58 ` Krzysztof Halasa
2003-08-25 8:50 ` Jes Sorensen
2003-08-30 21:18 ` Krzysztof Halasa
2003-08-31 1:50 ` David S. Miller
2003-08-31 12:52 ` Alan Cox
2003-08-31 15:24 ` Krzysztof Halasa
2003-09-01 5:22 ` David S. Miller
2003-09-01 7:34 ` Krzysztof Halasa
2003-09-01 7:43 ` David S. Miller
2003-09-01 17:14 ` Krzysztof Halasa [this message]
2003-09-01 17:28 ` David S. Miller
2003-09-01 18:24 ` Krzysztof Halasa
2003-09-01 7:54 ` Alan Cox
2003-09-01 7:52 ` David S. Miller
2003-09-01 16:27 ` Krzysztof Halasa
2003-09-01 17:33 ` David S. Miller
2003-08-25 8:47 ` Jes Sorensen
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=m3ptikctx5.fsf@defiant.pm.waw.pl \
--to=khc@pm.waw.pl \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=davem@redhat.com \
--cc=jes@trained-monkey.org \
--cc=linux-kernel@vger.kernel.org \
--cc=zaitcev@redhat.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;
as well as URLs for NNTP newsgroup(s).