From: Krzysztof Halasa <khc@pm.waw.pl>
To: <linux-kernel@vger.kernel.org>
Subject: consistent_dma_mask is a ghost?
Date: 12 Aug 2003 01:07:32 +0200 [thread overview]
Message-ID: <m3lltzssi3.fsf@defiant.pm.waw.pl> (raw)
[Repost, not sure why it haven't reach the list]
Hi,
I've run grep over the linux-2.6.0-test3 tree and it seems the whole
"consistent_dma_mask" thing does not really exist.
The following files reference it, either as a variable struct pci_dev*
dev->consistent_dma_mask or function set_consistent_dma_mask():
drivers/net/tg3.c: sets both consistent_dma_mask and dma_mask to 2^64-1,
and if that fails to 2^32-1.
drivers/atm/lanai.c: sets both to 2^32-1 = the default
drivers/pci/pci.c: the function pci_set_consistent_dma_mask() itself
drivers/pci/probe.c: sets default 2^32-1 for a device;
arch/ia64/sn/io/machvec/pci_dma.c: sn_pci_alloc_consistent() actually uses
consistent_dma_mask
arch/x86_64/kernel/pci-gart.c: pci_alloc_consistent() actually uses
consistent_dma_mask
This means that only _two_ platforms, ia64 and x86_64, have means to use
that information, and other platforms use set_dma_mask() and dev->dma_mask
for consistent (coherent) allocations ignoring consistent_dma_mask at all
(and possibly allocating memory from invalid region, if the masks are
not equal).
No wonder even on those two platforms no code uses consistent_dma_mask
to do some real work - i.e. both tg3 and lanai drivers use the same value
for consistent and streaming mapping. The "DMA" API doesn't have anything
like this either.
Is the whole thing a work in progress, only partially merged, and will we
see this working as documented, or should we just remove all traces of
useless consistent_dma_mask and use a single dma_mask for both kinds of
mapping? Should I prepare the patch?
Another problem, common to DMA API and PCI API:
Unless I'm mistaken, both dma_map_* and pci_map_* claim to use dma_mask
to return dma_addr_t bus address for a device. At least on i386, there
is no such thing at all - the returned address is just a result of
virt_to_phys(), and is not limited by the mask. I understand doing that
in accordance to the docs would sometimes mean memcpy() (with devices
using smaller than 2^32-1 dma_mask). Should the code be corrected/added
or are the docs to be changed to reflect reality?
--
Krzysztof Halasa
Network Administrator
next reply other threads:[~2003-08-11 23:08 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-11 23:07 Krzysztof Halasa [this message]
[not found] <mailman.1060643897.16128.linux-kernel2news@redhat.com>
2003-08-13 0:11 ` consistent_dma_mask is a ghost? Pete Zaitcev
2003-08-13 11:23 ` Alan Cox
2003-08-13 14:51 ` Krzysztof Halasa
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=m3lltzssi3.fsf@defiant.pm.waw.pl \
--to=khc@pm.waw.pl \
--cc=linux-kernel@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