public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* RE: [patch 2.6.13 0/6] swiotlb maintenance and x86_64 dma_sync_single_range_for_{cpu,device}
@ 2005-09-23 18:27 Luck, Tony
  2005-09-23 18:50 ` John W. Linville
                   ` (2 more replies)
  0 siblings, 3 replies; 16+ messages in thread
From: Luck, Tony @ 2005-09-23 18:27 UTC (permalink / raw)
  To: John W. Linville, Christoph Hellwig, linux-kernel, discuss,
	linux-ia64, ak, Mallick, Asit K

>> It should just go away once the GFP_DMA32 code is merged.
>
>Is that the plan?  I suppose it makes sense.
>
>So, move it to driver/pci/swiotlb.c?  Or just leave it where it is?
>
>Either way, I'll redo the other patches to reflect the correct
>location.

I don't have a good (or in fact any) understanding of the impact
of GFP_DMA32 on ia64.  People tell me it will all be good, but I'd
like to hear from someone running it.

If it is good, and if it is coming soon, then there is no point
moving swiotlb.  But I don't know the answers to either of those
questions.

-Tony

^ permalink raw reply	[flat|nested] 16+ messages in thread
* RE: [patch 2.6.14-rc2 0/5] swiotlb maintenance and x86_64 dma_sync_single_range_for_{cpu,device}
@ 2005-09-26 22:08 Luck, Tony
  2005-09-26 22:46 ` Grant Grundler
  0 siblings, 1 reply; 16+ messages in thread
From: Luck, Tony @ 2005-09-26 22:08 UTC (permalink / raw)
  To: John W. Linville, Matthew Wilcox
  Cc: linux-kernel, discuss, linux-ia64, linux-pci, ak, Mallick, Asit K,
	gregkh

[-- Attachment #1: Type: text/plain, Size: 1040 bytes --]

>Well, now, this is a quandry isn't it...  Actually, I'm inclined to
>agree with you.
>
>Tony, et al., care to restate your reasoning for moving it under
>drivers/pci?

Historically swiotlb.c was written with just PCI in mind (hence
all the comments ("... implement the PCI DMA API",  "The PCI address
to use is returned", "teardown the PCI dma mapping") and a few
error messages ("PCI-DMA: Out of SW-IOMMU space ...", "PCI-DMA: Memory
would be corrupted", "PCI-DMA: Random memory would be DMAed").
Perhaps back then the only options were PCI and ISA????

Matthew is probably technically right in that this is a more
generic interface ... but is it actually being used for anything
other than PCI?  Will it ever be so used?

Ignoring the comments and error messages, the attached patch
removed the <linux/pci.h> and <asm/pci.h> includes (and adds a
couple of others that are then needed, and converts a few
PCI_DMA_* defines to DMA_* ones that sound like they mean the
same thing).  Compiles, but not tested.

-Tony

[-- Attachment #2: sw.patch --]
[-- Type: application/octet-stream, Size: 1031 bytes --]

--- a/arch/ia64/lib/swiotlb.c	2005-09-26 13:03:04.000000000 -0700
+++ b/arch/ia64/lib/swiotlb.c	2005-09-26 14:54:38.000000000 -0700
@@ -15,17 +15,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>
@@ -391,9 +391,9 @@
 	       "device %s\n", size, dev ? dev->bus_id : "?");
 
 	if (size > io_tlb_overflow && do_panic) {
-		if (dir == PCI_DMA_FROMDEVICE || dir == PCI_DMA_BIDIRECTIONAL)
+		if (dir == DMA_FROM_DEVICE || dir == DMA_BIDIRECTIONAL)
 			panic("PCI-DMA: Memory would be corrupted\n");
-		if (dir == PCI_DMA_TODEVICE || dir == PCI_DMA_BIDIRECTIONAL)
+		if (dir == DMA_TO_DEVICE || dir == DMA_BIDIRECTIONAL)
 			panic("PCI-DMA: Random memory would be DMAed\n");
 	}
 }

^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2005-09-27  2:47 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-09-23 18:27 [patch 2.6.13 0/6] swiotlb maintenance and x86_64 dma_sync_single_range_for_{cpu,device} 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
  -- strict thread matches above, loose matches on Subject: below --
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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox