linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 0/13] x86: unifying ways to handle multiple sets of dma mapping ops
@ 2009-01-05 14:47 FUJITA Tomonori
  2009-01-05 14:47 ` [PATCH 1/8] add map_page and unmap_page to struct dma_mapping_ops FUJITA Tomonori
  2009-01-05 15:00 ` [PATCH 0/13] x86: unifying ways to handle multiple sets of dma mapping ops FUJITA Tomonori
  0 siblings, 2 replies; 16+ messages in thread
From: FUJITA Tomonori @ 2009-01-05 14:47 UTC (permalink / raw)
  To: mingo; +Cc: linux-kernel, fujita.tomonori

This patchset is the second part of the unification of ways to handle
multiple sets of dma mapping API. The whole work consists of three
patchset. This is for X86 and can be applied independently (against
tip/master).

I've submitted the first part (for IA64):

http://marc.info/?l=linux-kernel&m=123116676006794&w=2

dma_mapping_ops (or dma_ops) struct is used to handle multiple sets of
dma mapping API by X86, SPARC, and POWER. IA64 also handle multiple
sets of dma mapping API but in a very different way (some define
magic).

X86 and IA64 share VT-d and SWIOTLB code. We need several workarounds
for it because of the deference of ways to handle multiple sets of dma
mapping API (e.g., X86 people can't freely change struct
dma_mapping_ops in x86's dma-mapping.h now because it could break
IA64).  Seems POWER will use SWIOTLB code soon. I think that it's time
to unify ways to handle multiple sets of dma mapping API. After
applying the whole work, we have struct dma_map_ops
include/linux/dma-mapping.h (I also dream of changing all the archs to
use SWIOTLB in order to remove the bounce code in the block and
network stacks...).

This patchset doesn't include major changes, just converting x86's
dma_mapping_ops to use map_page and unmap_page instead of map_single
and unmap_single. Currently, x86's dma_mapping_ops uses physical
address as a map_single's argument. But it's confusing since
dma_map_single uses a virtual address argument. So I chose POWER
dma_mapping_ops scheme, which uses map_page to handle dma_map_single.

=
 arch/x86/include/asm/dma-mapping.h |   23 ++++++++++++++---------
 arch/x86/kernel/amd_iommu.c        |   16 ++++++++++------
 arch/x86/kernel/pci-calgary_64.c   |   23 +++++++++++++----------
 arch/x86/kernel/pci-gart_64.c      |   20 ++++++++++++--------
 arch/x86/kernel/pci-nommu.c        |   16 ++++++++--------
 arch/x86/kernel/pci-swiotlb_64.c   |   22 ++++++++++++++++------
 drivers/pci/intel-iommu.c          |   26 ++++++++++++++++++++++----
 7 files changed, 95 insertions(+), 51 deletions(-)




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

end of thread, other threads:[~2009-01-06 13:08 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-01-05 14:47 [PATCH 0/13] x86: unifying ways to handle multiple sets of dma mapping ops FUJITA Tomonori
2009-01-05 14:47 ` [PATCH 1/8] add map_page and unmap_page to struct dma_mapping_ops FUJITA Tomonori
2009-01-05 14:47   ` [PATCH 2/8] swiotlb: add map_page and unmap_page FUJITA Tomonori
2009-01-05 14:47     ` [PATCH 3/8] gart: " FUJITA Tomonori
2009-01-05 14:47       ` [PATCH 4/8] calgary: " FUJITA Tomonori
2009-01-05 14:47         ` [PATCH 5/8] AMD IOMMU: " FUJITA Tomonori
2009-01-05 14:47           ` [PATCH 6/8] intel-iommu: " FUJITA Tomonori
2009-01-05 14:47             ` [PATCH 7/8] pci-nommu: add map_page FUJITA Tomonori
2009-01-05 14:47               ` [PATCH 8/8] remove map_single and unmap_single in struct dma_mapping_ops FUJITA Tomonori
2009-01-05 18:00                 ` Joerg Roedel
2009-01-06 10:22                   ` FUJITA Tomonori
2009-01-06  8:32         ` [PATCH 4/8] calgary: add map_page and unmap_page Muli Ben-Yehuda
2009-01-06 13:07           ` Ingo Molnar
2009-01-05 17:26   ` [PATCH 1/8] add map_page and unmap_page to struct dma_mapping_ops Joerg Roedel
2009-01-05 17:28     ` Joerg Roedel
2009-01-05 15:00 ` [PATCH 0/13] x86: unifying ways to handle multiple sets of dma mapping ops FUJITA Tomonori

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