From: "Luck, Tony" <tony.luck@intel.com>
To: "John W. Linville" <linville@tuxdriver.com>
Cc: linux-kernel@vger.kernel.org, discuss@x86-64.org,
linux-ia64@vger.kernel.org, linux-pci@atrey.karlin.mff.cuni.cz,
ak@suse.de, Asit.K.Mallick@intel.com, gregkh@suse.de
Subject: Re: [patch 2.6.14-rc2 0/6] swiotlb maintenance and x86_64 dma_sync_single_range_for_{cpu,device}
Date: Thu, 29 Sep 2005 22:42:02 +0000 [thread overview]
Message-ID: <20050929224202.GA15263@agluck-lia64.sc.intel.com> (raw)
In-Reply-To: <09282005175047.10096@bilbo.tuxdriver.com>
On Wed, Sep 28, 2005 at 05:50:47PM -0400, John W. Linville wrote:
> This set does NOT include the PCI excision that Tony Luck started after the
> last round of discussion.
Here's my attempt at part 7of6 to complete the removal of references
to PCI. This time I fixed all the comments and printk() messages.
I even checked that it compiles on x86_64/em64t.
There will be some small amount of fuzz in this patch as I started
applying from a base that included a patch from Alex Williamson.
Andi: earlier you had made positive noises about moving
swiotlb.c up to lib/ ... now we have a specific implementation
can you confirm that you are still OK with this. If you are,
then I'll put this whole series into my test tree so it will
get into the next -mm release.
Signed-off-by: Tony Luck <tony.luck@intel.com>
---
diff --git a/lib/swiotlb.c b/lib/swiotlb.c
--- a/lib/swiotlb.c
+++ b/lib/swiotlb.c
@@ -17,17 +17,17 @@
*/
#include <linux/cache.h>
+#include <linux/dma-mapping.h>
#include <linux/mm.h>
#include <linux/module.h>
-#include <linux/pci.h>
#include <linux/spinlock.h>
#include <linux/string.h>
#include <linux/types.h>
#include <linux/ctype.h>
#include <asm/io.h>
-#include <asm/pci.h>
#include <asm/dma.h>
+#include <asm/scatterlist.h>
#include <linux/init.h>
#include <linux/bootmem.h>
@@ -127,7 +127,7 @@ __setup("swiotlb=", setup_io_tlb_npages)
/*
* Statically reserve bounce buffer space and initialize bounce buffer data
- * structures for the software IO TLB used to implement the PCI DMA API.
+ * structures for the software IO TLB used to implement the DMA API.
*/
void
swiotlb_init_with_default_size (size_t default_size)
@@ -502,24 +502,24 @@ swiotlb_full(struct device *dev, size_t
/*
* Ran out of IOMMU space for this operation. This is very bad.
* Unfortunately the drivers cannot handle this operation properly.
- * unless they check for pci_dma_mapping_error (most don't)
+ * unless they check for dma_mapping_error (most don't)
* When the mapping is small enough return a static buffer to limit
* the damage, or panic when the transfer is too big.
*/
- printk(KERN_ERR "PCI-DMA: Out of SW-IOMMU space for %lu bytes at "
+ printk(KERN_ERR "DMA: Out of SW-IOMMU space for %lu bytes at "
"device %s\n", size, dev ? dev->bus_id : "?");
if (size > io_tlb_overflow && do_panic) {
- if (dir = PCI_DMA_FROMDEVICE || dir = PCI_DMA_BIDIRECTIONAL)
- panic("PCI-DMA: Memory would be corrupted\n");
- if (dir = PCI_DMA_TODEVICE || dir = PCI_DMA_BIDIRECTIONAL)
- panic("PCI-DMA: Random memory would be DMAed\n");
+ if (dir = DMA_FROM_DEVICE || dir = DMA_BIDIRECTIONAL)
+ panic("DMA: Memory would be corrupted\n");
+ if (dir = DMA_TO_DEVICE || dir = DMA_BIDIRECTIONAL)
+ panic("DMA: Random memory would be DMAed\n");
}
}
/*
* Map a single buffer of the indicated size for DMA in streaming mode. The
- * PCI address to use is returned.
+ * physical address to use is returned.
*
* Once the device is given the dma address, the device owns this memory until
* either swiotlb_unmap_single or swiotlb_dma_sync_single is performed.
@@ -606,8 +606,8 @@ swiotlb_unmap_single(struct device *hwde
* after a transfer.
*
* If you perform a swiotlb_map_single() but wish to interrogate the buffer
- * using the cpu, yet do not wish to teardown the PCI dma mapping, you must
- * call this function before doing so. At the next point you give the PCI dma
+ * using the cpu, yet do not wish to teardown the dma mapping, you must
+ * call this function before doing so. At the next point you give the dma
* address back to the card, you must first perform a
* swiotlb_dma_sync_for_device, and then the device again owns the buffer
*/
@@ -783,9 +783,9 @@ swiotlb_dma_mapping_error(dma_addr_t dma
}
/*
- * Return whether the given PCI device DMA address mask can be supported
+ * Return whether the given device DMA address mask can be supported
* properly. For example, if your device can only drive the low 24-bits
- * during PCI bus mastering, then you would pass 0x00ffffff as the mask to
+ * during bus mastering, then you would pass 0x00ffffff as the mask to
* this function.
*/
int
prev parent reply other threads:[~2005-09-29 22:42 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20050829200916.GI3716@tuxdriver.com>
[not found] ` <200508292254.53476.ak@suse.de>
[not found] ` <20050829214828.GA6314@tuxdriver.com>
[not found] ` <200508300314.35177.ak@suse.de>
[not found] ` <20050830175436.GB18998@tuxdriver.com>
2005-08-30 17:58 ` [patch 2.6.13] swiotlb: add swiotlb_sync_single_range_for_{cpu,device} John W. Linville
2005-08-30 18:03 ` Luck, Tony
2005-08-30 18:09 ` John W. Linville
2005-08-30 18:33 ` [rfc patch] swiotlb: consolidate swiotlb_sync_single_* implementations John W. Linville
2005-08-30 18:40 ` [rfc patch] swiotlb: consolidate swiotlb_sync_sg_* implementations John W. Linville
2005-09-12 14:48 ` [patch 2.6.13 0/6] swiotlb maintenance and x86_64 dma_sync_single_range_for_{cpu,device} John W. Linville
2005-09-12 14:48 ` [patch 2.6.13 1/6] swiotlb: move from arch/ia64/lib to lib John W. Linville
2005-09-12 14:48 ` [patch 2.6.13 2/6] swiotlb: cleanup some code duplication cruft John W. Linville
2005-09-12 14:48 ` [patch 2.6.13 3/6] swiotlb: support syncing sub-ranges of mappings John W. Linville
2005-09-12 14:48 ` [patch 2.6.13 4/6] swiotlb: support syncing DMA_BIDIRECTIONAL mappings John W. Linville
2005-09-12 14:48 ` [patch 2.6.13 5/6] swiotlb: file header comments John W. Linville
2005-09-12 18:51 ` [patch 2.6.13 4/6] swiotlb: support syncing DMA_BIDIRECTIONAL mappings Grant Grundler
2005-09-12 19:51 ` John W. Linville
2005-09-12 19:53 ` [patch 2.6.13] swiotlb: BUG() for DMA_NONE in sync_single John W. Linville
2005-09-12 20:23 ` Grant Grundler
2005-09-12 23:45 ` [patch 2.6.13 (take #2)] " John W. Linville
2005-09-12 23:59 ` Grant Grundler
2005-09-13 4:05 ` [discuss] " Andi Kleen
2005-09-22 20:37 ` [patch 2.6.13 0/6] swiotlb maintenance and x86_64 dma_sync_single_range_for_{cpu,device} Luck, Tony
2005-09-22 20:41 ` Christoph Hellwig
2005-09-23 18:22 ` John W. Linville
2005-09-23 18:31 ` Muli Ben-Yehuda
2005-09-23 18:27 ` Luck, Tony
2005-09-23 18:50 ` John W. Linville
2005-09-23 21:38 ` Grant Grundler
2005-09-26 7:01 ` Andi Kleen
2005-09-26 21:01 ` [patch 2.6.14-rc2 0/5] " John W. Linville
2005-09-26 21:01 ` [patch 2.6.14-rc2 1/5] swiotlb: move from arch/ia64/lib to drivers/pci John W. Linville
2005-09-26 21:01 ` [patch 2.6.14-rc2 2/5] swiotlb: cleanup some code duplication cruft John W. Linville
2005-09-26 21:01 ` [patch 2.6.14-rc2 3/5] swiotlb: support syncing sub-ranges of mappings John W. Linville
2005-09-26 21:01 ` [patch 2.6.14-rc2 4/5] swiotlb: support syncing DMA_BIDIRECTIONAL mappings John W. Linville
2005-09-26 21:01 ` [patch 2.6.14-rc2 5/5] swiotlb: file header comments John W. Linville
2005-09-26 21:33 ` [patch 2.6.14-rc2 0/5] swiotlb maintenance and x86_64 dma_sync_single_range_for_{cpu,device} Matthew Wilcox
2005-09-26 21:54 ` John W. Linville
2005-09-26 22:08 ` Luck, Tony
2005-09-26 22:46 ` Grant Grundler
2005-09-27 0:14 ` John W. Linville
2005-09-27 2:47 ` Tony Luck
2005-09-28 21:50 ` [patch 2.6.14-rc2 0/6] " John W. Linville
2005-09-28 21:50 ` [patch 2.6.14-rc2 1/6] swiotlb: move from arch/ia64/lib/ to lib/ John W. Linville
2005-09-28 21:50 ` [patch 2.6.14-rc2 2/6] swiotlb: cleanup some code duplication cruft John W. Linville
2005-09-28 21:50 ` [patch 2.6.14-rc2 3/6] swiotlb: support syncing sub-ranges of mappings John W. Linville
2005-09-28 21:50 ` [patch 2.6.14-rc2 4/6] swiotlb: support syncing DMA_BIDIRECTIONAL mappings John W. Linville
2005-09-28 21:50 ` [patch 2.6.14-rc2 5/6] swiotlb: file header comments John W. Linville
2005-09-29 22:42 ` Luck, Tony [this message]
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=20050929224202.GA15263@agluck-lia64.sc.intel.com \
--to=tony.luck@intel.com \
--cc=Asit.K.Mallick@intel.com \
--cc=ak@suse.de \
--cc=discuss@x86-64.org \
--cc=gregkh@suse.de \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@atrey.karlin.mff.cuni.cz \
--cc=linville@tuxdriver.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