linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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


  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).