swiotlb: remove duplicated #include

swiotlb: remove duplicated #include

[Huang Weiyi]

Removed duplicated #include in lib/swiotlb.c.

Signed-off-by: Huang Weiyi <weiyi.huang@gmail.com>

diff --git a/lib/swiotlb.c b/lib/swiotlb.c
index fa2dc4e..c3fbcd8 100644
--- a/lib/swiotlb.c
+++ b/lib/swiotlb.c
@@ -23,7 +23,6 @@
 #include <linux/spinlock.h>
 #include <linux/swiotlb.h>
 #include <linux/string.h>
-#include <linux/swiotlb.h>
 #include <linux/types.h>
 #include <linux/ctype.h>
 #include <linux/highmem.h>

Re: swiotlb: remove duplicated #include

[Jesper Juhl]

On Sun, 4 Jan 2009, Huang Weiyi wrote:

> Removed duplicated #include in lib/swiotlb.c.
> 

This is identical to a patch I already submitted - 
http://lkml.org/lkml/2009/1/2/360 - but I don't know if that one has been 
merged anywhere yet.

-- 
Jesper Juhl <jj@chaosbits.net>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: swiotlb: remove duplicated #include

[Ingo Molnar]

* Jesper Juhl <jj@chaosbits.net> wrote:

> On Sun, 4 Jan 2009, Huang Weiyi wrote:
> 
> > Removed duplicated #include in lib/swiotlb.c.
> > 
> 
> This is identical to a patch I already submitted - 
> http://lkml.org/lkml/2009/1/2/360 - but I don't know if that one has been 
> merged anywhere yet.

i've applied yours to tip/core/urgent, thanks Jesper!

	Ingo

Re: swiotlb: remove duplicated #include

[FUJITA Tomonori]

On Sun, 4 Jan 2009 12:25:43 +0100
Ingo Molnar <mingo@elte.hu> wrote:

> 
> * Jesper Juhl <jj@chaosbits.net> wrote:
> 
> > On Sun, 4 Jan 2009, Huang Weiyi wrote:
> > 
> > > Removed duplicated #include in lib/swiotlb.c.
> > > 
> > 
> > This is identical to a patch I already submitted - 
> > http://lkml.org/lkml/2009/1/2/360 - but I don't know if that one has been 
> > merged anywhere yet.
> 
> i've applied yours to tip/core/urgent, thanks Jesper!

The same cleanup is in tip/core/iommu:

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


My cleanup patches in it are trivial, but I like to see Becky's
swiotlb highmem work, which is still in tip/core/iommu. When do you
plan to push it to mainline?

Re: swiotlb: remove duplicated #include

[Ingo Molnar]

* FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> wrote:

> On Sun, 4 Jan 2009 12:25:43 +0100
> Ingo Molnar <mingo@elte.hu> wrote:
> 
> > 
> > * Jesper Juhl <jj@chaosbits.net> wrote:
> > 
> > > On Sun, 4 Jan 2009, Huang Weiyi wrote:
> > > 
> > > > Removed duplicated #include in lib/swiotlb.c.
> > > > 
> > > 
> > > This is identical to a patch I already submitted - 
> > > http://lkml.org/lkml/2009/1/2/360 - but I don't know if that one has been 
> > > merged anywhere yet.
> > 
> > i've applied yours to tip/core/urgent, thanks Jesper!
> 
> The same cleanup is in tip/core/iommu:
> 
> http://marc.info/?l=linux-kernel&m=123044446721529&w=2

yes, correct - as part of Becky and Jeremy's highmem series.

> My cleanup patches in it are trivial, but I like to see Becky's swiotlb 
> highmem work, which is still in tip/core/iommu. When do you plan to push 
> it to mainline?

In a few days, but wanted to hear back from either Jeremy or Becky first 
about how well they actually work in their usecases.

	Ingo

Re: swiotlb: remove duplicated #include

[FUJITA Tomonori]

On Sun, 4 Jan 2009 13:19:14 +0100
Ingo Molnar <mingo@elte.hu> wrote:

> 
> * FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> wrote:
> 
> > On Sun, 4 Jan 2009 12:25:43 +0100
> > Ingo Molnar <mingo@elte.hu> wrote:
> > 
> > > 
> > > * Jesper Juhl <jj@chaosbits.net> wrote:
> > > 
> > > > On Sun, 4 Jan 2009, Huang Weiyi wrote:
> > > > 
> > > > > Removed duplicated #include in lib/swiotlb.c.
> > > > > 
> > > > 
> > > > This is identical to a patch I already submitted - 
> > > > http://lkml.org/lkml/2009/1/2/360 - but I don't know if that one has been 
> > > > merged anywhere yet.
> > > 
> > > i've applied yours to tip/core/urgent, thanks Jesper!
> > 
> > The same cleanup is in tip/core/iommu:
> > 
> > http://marc.info/?l=linux-kernel&m=123044446721529&w=2
> 
> yes, correct - as part of Becky and Jeremy's highmem series.
> 
> > My cleanup patches in it are trivial, but I like to see Becky's swiotlb 
> > highmem work, which is still in tip/core/iommu. When do you plan to push 
> > it to mainline?
> 
> In a few days, but wanted to hear back from either Jeremy or Becky first 
> about how well they actually work in their usecases.

Well, you don't need to wait, I think.

All Jeremy and Becky need is adding highmem support to swiotlb. How we
support it doesn't matter. We can choose better one.

We all (including Jeremy) agreed that Becky's physical address scheme
is better (simpler) than Jeremy's struct page and offset
scheme. Surely, Becky's scheme works for Xen and him (Jeremy said that
he tested it lightly).

One remaining issue is how to support map_page/unmap_page. As we
discussed, we can add some workarounds for it but it's better to unify
dma_mapping_ops. I send patches to do it after testing them on an IA64
box tomorrow.

Re: swiotlb: remove duplicated #include

[Ingo Molnar]

* FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> wrote:

> > In a few days, but wanted to hear back from either Jeremy or Becky 
> > first about how well they actually work in their usecases.
> 
> Well, you don't need to wait, I think.
> 
> All Jeremy and Becky need is adding highmem support to swiotlb. How we 
> support it doesn't matter. We can choose better one.
> 
> We all (including Jeremy) agreed that Becky's physical address scheme is 
> better (simpler) than Jeremy's struct page and offset scheme. Surely, 
> Becky's scheme works for Xen and him (Jeremy said that he tested it 
> lightly).

Jeremy said, when he submitted this series, shortly before Christmas:

 >> Here's a work in progress series [...]
 >>
 >> Quick testing showed no problems, but I haven't had the chance to do 
 >> anything extensive.

Jeremy, did you have a chance to do more testing with the current 
tip/master bits on Xen, so that we can push it to Linus?

> One remaining issue is how to support map_page/unmap_page. As we 
> discussed, we can add some workarounds for it but it's better to unify 
> dma_mapping_ops. I send patches to do it after testing them on an IA64 
> box tomorrow.

ok.

	Ingo

Re: swiotlb: remove duplicated #include

[Jeremy Fitzhardinge]

Ingo Molnar wrote:
> * FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> wrote:
>
>   
>>> In a few days, but wanted to hear back from either Jeremy or Becky 
>>> first about how well they actually work in their usecases.
>>>       
>> Well, you don't need to wait, I think.
>>
>> All Jeremy and Becky need is adding highmem support to swiotlb. How we 
>> support it doesn't matter. We can choose better one.
>>
>> We all (including Jeremy) agreed that Becky's physical address scheme is 
>> better (simpler) than Jeremy's struct page and offset scheme. Surely, 
>> Becky's scheme works for Xen and him (Jeremy said that he tested it 
>> lightly).
>>     
>
> Jeremy said, when he submitted this series, shortly before Christmas:
>
>  >> Here's a work in progress series [...]
>  >>
>  >> Quick testing showed no problems, but I haven't had the chance to do 
>  >> anything extensive.
>
> Jeremy, did you have a chance to do more testing with the current 
> tip/master bits on Xen, so that we can push it to Linus?
>   

I'm going to be on vacation until the 12th, so I won't have a chance to 
do anything until then (perhaps Ian will have a chance to poke at them 
before then).  I'm expecting Becky's patches to work as-is, or if not, 
be easily fixed with a couple of small bugfix patches.  So I say go 
ahead if they work for everyone else.

    J

Re: swiotlb: remove duplicated #include

[FUJITA Tomonori]

On Mon, 05 Jan 2009 09:48:36 +1100
Jeremy Fitzhardinge <jeremy@goop.org> wrote:

> Ingo Molnar wrote:
> > * FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> wrote:
> >
> >   
> >>> In a few days, but wanted to hear back from either Jeremy or Becky 
> >>> first about how well they actually work in their usecases.
> >>>       
> >> Well, you don't need to wait, I think.
> >>
> >> All Jeremy and Becky need is adding highmem support to swiotlb. How we 
> >> support it doesn't matter. We can choose better one.
> >>
> >> We all (including Jeremy) agreed that Becky's physical address scheme is 
> >> better (simpler) than Jeremy's struct page and offset scheme. Surely, 
> >> Becky's scheme works for Xen and him (Jeremy said that he tested it 
> >> lightly).
> >>     
> >
> > Jeremy said, when he submitted this series, shortly before Christmas:
> >
> >  >> Here's a work in progress series [...]
> >  >>
> >  >> Quick testing showed no problems, but I haven't had the chance to do 
> >  >> anything extensive.
> >
> > Jeremy, did you have a chance to do more testing with the current 
> > tip/master bits on Xen, so that we can push it to Linus?
> >   
> 
> I'm going to be on vacation until the 12th, so I won't have a chance to 
> do anything until then (perhaps Ian will have a chance to poke at them 
> before then).  I'm expecting Becky's patches to work as-is, or if not, 
> be easily fixed with a couple of small bugfix patches.  So I say go 
> ahead if they work for everyone else.

Yeah, technically, Becky's scheme should work for Xen. We already
decided to go with his scheme. So it's better to push his patchset to
mainline now to make sure it doesn't break the existing swiotlb users
rather than keeping and testing the code that we will replace.

Re: swiotlb: remove duplicated #include

[Ingo Molnar]

* Jeremy Fitzhardinge <jeremy@goop.org> wrote:

> Ingo Molnar wrote:
>> * FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> wrote:
>>
>>   
>>>> In a few days, but wanted to hear back from either Jeremy or Becky  
>>>> first about how well they actually work in their usecases.
>>>>       
>>> Well, you don't need to wait, I think.
>>>
>>> All Jeremy and Becky need is adding highmem support to swiotlb. How 
>>> we support it doesn't matter. We can choose better one.
>>>
>>> We all (including Jeremy) agreed that Becky's physical address scheme 
>>> is better (simpler) than Jeremy's struct page and offset scheme. 
>>> Surely, Becky's scheme works for Xen and him (Jeremy said that he 
>>> tested it lightly).
>>>     
>>
>> Jeremy said, when he submitted this series, shortly before Christmas:
>>
>>  >> Here's a work in progress series [...]
>>  >>
>>  >> Quick testing showed no problems, but I haven't had the chance to 
>> do  >> anything extensive.
>>
>> Jeremy, did you have a chance to do more testing with the current  
>> tip/master bits on Xen, so that we can push it to Linus?
>>   
>
> I'm going to be on vacation until the 12th, so I won't have a chance to 
> do anything until then (perhaps Ian will have a chance to poke at them 
> before then).  I'm expecting Becky's patches to work as-is, or if not, 
> be easily fixed with a couple of small bugfix patches.  So I say go 
> ahead if they work for everyone else.

ok, i have put it into the to-Linus pile.

	Ingo

Re: swiotlb: remove duplicated #include

[Ian Campbell]

On Mon, 2009-01-05 at 09:48 +1100, Jeremy Fitzhardinge wrote:
> Ingo Molnar wrote:
> > * FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> wrote:
> >
> >   
> >>> In a few days, but wanted to hear back from either Jeremy or Becky 
> >>> first about how well they actually work in their usecases.
> >>>       
> >> Well, you don't need to wait, I think.
> >>
> >> All Jeremy and Becky need is adding highmem support to swiotlb. How we 
> >> support it doesn't matter. We can choose better one.
> >>
> >> We all (including Jeremy) agreed that Becky's physical address scheme is 
> >> better (simpler) than Jeremy's struct page and offset scheme. Surely, 
> >> Becky's scheme works for Xen and him (Jeremy said that he tested it 
> >> lightly).
> >>     
> >
> > Jeremy said, when he submitted this series, shortly before Christmas:
> >
> >  >> Here's a work in progress series [...]
> >  >>
> >  >> Quick testing showed no problems, but I haven't had the chance to do 
> >  >> anything extensive.
> >
> > Jeremy, did you have a chance to do more testing with the current 
> > tip/master bits on Xen, so that we can push it to Linus?
> >   
> 
> I'm going to be on vacation until the 12th, so I won't have a chance to 
> do anything until then (perhaps Ian will have a chance to poke at them 
> before then).  I'm expecting Becky's patches to work as-is, or if not, 
> be easily fixed with a couple of small bugfix patches.  So I say go 
> ahead if they work for everyone else.

Only just got out from under my pile of vacation backlog...

They don't quite work with Xen (at least the version in Jeremy's patch
queue doesn't) but I agree that it should be possible to make it work
and that there's no point in holding back just for Xen.

Ian.

> 
>     J
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: swiotlb: remove duplicated #include

[Becky Bruce]

On Jan 9, 2009, at 10:37 AM, Ian Campbell wrote:

> On Mon, 2009-01-05 at 09:48 +1100, Jeremy Fitzhardinge wrote:
>> Ingo Molnar wrote:
>>> * FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> wrote:
>>>
>>>
>>>>> In a few days, but wanted to hear back from either Jeremy or Becky
>>>>> first about how well they actually work in their usecases.
>>>>>
>>>> Well, you don't need to wait, I think.
>>>>
>>>> All Jeremy and Becky need is adding highmem support to swiotlb.  
>>>> How we
>>>> support it doesn't matter. We can choose better one.
>>>>
>>>> We all (including Jeremy) agreed that Becky's physical address  
>>>> scheme is
>>>> better (simpler) than Jeremy's struct page and offset scheme.  
>>>> Surely,
>>>> Becky's scheme works for Xen and him (Jeremy said that he tested it
>>>> lightly).
>>>>
>>>
>>> Jeremy said, when he submitted this series, shortly before  
>>> Christmas:
>>>
>>>>> Here's a work in progress series [...]
>>>>>
>>>>> Quick testing showed no problems, but I haven't had the chance  
>>>>> to do
>>>>> anything extensive.
>>>
>>> Jeremy, did you have a chance to do more testing with the current
>>> tip/master bits on Xen, so that we can push it to Linus?
>>>
>>
>> I'm going to be on vacation until the 12th, so I won't have a  
>> chance to
>> do anything until then (perhaps Ian will have a chance to poke at  
>> them
>> before then).  I'm expecting Becky's patches to work as-is, or if  
>> not,
>> be easily fixed with a couple of small bugfix patches.  So I say go
>> ahead if they work for everyone else.
>
> Only just got out from under my pile of vacation backlog...
>
> They don't quite work with Xen (at least the version in Jeremy's patch
> queue doesn't) but I agree that it should be possible to make it work
> and that there's no point in holding back just for Xen.

I'm also back (temporarily), and they're not quite going to work for  
powerpc, either, but it shouldn't be anything major to fix, and since  
it didn't work on powerpc before, that shouldn't hold anything up.   
I'm working on getting things working for me again now.   
Unfortunately, it now looks like I'm going to have to be out of the  
office next week, but I expect to get something out as soon as I'm  
back, if I don't get a chance to fix it today.

Jeremy, many thanks for your work merging my patches in with your  
series!

Cheers,
Becky

Re: swiotlb: remove duplicated #include

[Ian Campbell]

On Fri, 2009-01-09 at 11:36 -0600, Becky Bruce wrote:
> On Jan 9, 2009, at 10:37 AM, Ian Campbell wrote:
> 
> > On Mon, 2009-01-05 at 09:48 +1100, Jeremy Fitzhardinge wrote:
> >> Ingo Molnar wrote:
> >>> * FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> wrote:
> >>>
> >>>
> >>>>> In a few days, but wanted to hear back from either Jeremy or Becky
> >>>>> first about how well they actually work in their usecases.
> >>>>>
> >>>> Well, you don't need to wait, I think.
> >>>>
> >>>> All Jeremy and Becky need is adding highmem support to swiotlb.  
> >>>> How we
> >>>> support it doesn't matter. We can choose better one.
> >>>>
> >>>> We all (including Jeremy) agreed that Becky's physical address  
> >>>> scheme is
> >>>> better (simpler) than Jeremy's struct page and offset scheme.  
> >>>> Surely,
> >>>> Becky's scheme works for Xen and him (Jeremy said that he tested it
> >>>> lightly).
> >>>>
> >>>
> >>> Jeremy said, when he submitted this series, shortly before  
> >>> Christmas:
> >>>
> >>>>> Here's a work in progress series [...]
> >>>>>
> >>>>> Quick testing showed no problems, but I haven't had the chance  
> >>>>> to do
> >>>>> anything extensive.
> >>>
> >>> Jeremy, did you have a chance to do more testing with the current
> >>> tip/master bits on Xen, so that we can push it to Linus?
> >>>
> >>
> >> I'm going to be on vacation until the 12th, so I won't have a  
> >> chance to
> >> do anything until then (perhaps Ian will have a chance to poke at  
> >> them
> >> before then).  I'm expecting Becky's patches to work as-is, or if  
> >> not,
> >> be easily fixed with a couple of small bugfix patches.  So I say go
> >> ahead if they work for everyone else.
> >
> > Only just got out from under my pile of vacation backlog...
> >
> > They don't quite work with Xen (at least the version in Jeremy's patch
> > queue doesn't) but I agree that it should be possible to make it work
> > and that there's no point in holding back just for Xen.
> 
> I'm also back (temporarily), and they're not quite going to work for  
> powerpc, either, but it shouldn't be anything major to fix, and since  
> it didn't work on powerpc before, that shouldn't hold anything up.   
> I'm working on getting things working for me again now.   
> Unfortunately, it now looks like I'm going to have to be out of the  
> office next week, but I expect to get something out as soon as I'm  
> back, if I don't get a chance to fix it today.

I've got it working for Xen now, the only generic patch of consequence
is below. The others are to the Xen specific bits which haven't been
posted yet.

Patch is against Jeremy's Xen patch queue which is based on a pre-Xmas
tip tree so fairly out of date, I hope it is somewhat useful though.

Ian.

swiotlb: do not use sg_virt()

Scatterlists containing HighMem pages do not have a useful virtual
address. Use the physical address instead.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
diff -r 6c14c6035bf5 lib/swiotlb.c
--- a/lib/swiotlb.c	Fri Jan 09 17:57:19 2009 +0000
+++ b/lib/swiotlb.c	Fri Jan 09 17:58:04 2009 +0000
@@ -40,8 +40,6 @@
 
 #define OFFSET(val,align) ((unsigned long)	\
 	                   ( (val) & ( (align) - 1)))
-
-#define SG_ENT_BUS_ADDRESS(hwdev, sg)	swiotlb_virt_to_bus(hwdev, sg_virt(sg))
 
 #define SLABS_PER_PAGE (1 << (PAGE_SHIFT - IO_TLB_SHIFT))
 
@@ -815,10 +813,10 @@
 	BUG_ON(dir == DMA_NONE);
 
 	for_each_sg(sgl, sg, nelems, i) {
-		void *addr = sg_virt(sg);
-		dma_addr_t dev_addr = swiotlb_virt_to_bus(hwdev, addr);
+		phys_addr_t paddr = sg_phys(sg);
+		dma_addr_t dev_addr = swiotlb_phys_to_bus(hwdev, paddr);
 
-		if (range_needs_mapping(sg_phys(sg), sg->length) ||
+		if (range_needs_mapping(paddr, sg->length) ||
 		    address_needs_mapping(hwdev, dev_addr, sg->length)) {
 			void *map = map_single(hwdev, sg_phys(sg),
 					       sg->length, dir);
@@ -862,11 +860,11 @@
 	BUG_ON(dir == DMA_NONE);
 
 	for_each_sg(sgl, sg, nelems, i) {
-		if (sg->dma_address != SG_ENT_BUS_ADDRESS(hwdev, sg))
+		if (sg->dma_address != swiotlb_phys_to_bus(hwdev, sg_phys(sg)))
 			unmap_single(hwdev, swiotlb_bus_to_virt(sg->dma_address),
 				     sg->dma_length, dir);
 		else if (dir == DMA_FROM_DEVICE)
-			dma_mark_clean(sg_virt(sg), sg->dma_length);
+			dma_mark_clean(swiotlb_bus_to_virt(sg->dma_address), sg->dma_length);
 	}
 }
 EXPORT_SYMBOL(swiotlb_unmap_sg_attrs);
@@ -895,11 +893,11 @@
 	BUG_ON(dir == DMA_NONE);
 
 	for_each_sg(sgl, sg, nelems, i) {
-		if (sg->dma_address != SG_ENT_BUS_ADDRESS(hwdev, sg))
+		if (sg->dma_address != swiotlb_phys_to_bus(hwdev, sg_phys(sg)))
 			sync_single(hwdev, swiotlb_bus_to_virt(sg->dma_address),
 				    sg->dma_length, dir, target);
 		else if (dir == DMA_FROM_DEVICE)
-			dma_mark_clean(sg_virt(sg), sg->dma_length);
+			dma_mark_clean(swiotlb_bus_to_virt(sg->dma_address), sg->dma_length);
 	}
 }
 

[PATCH 0/2] Re: swiotlb: remove duplicated #include

[Ian Campbell]

On Fri, 2009-01-09 at 18:10 +0000, Ian Campbell wrote:

> Patch is against Jeremy's Xen patch queue which is based on a pre-Xmas
> tip tree so fairly out of date, I hope it is somewhat useful though.

Here's a version again tip-latest, only compile tested though since my
testing relies on the Xen dom0 patch queue.

[PATCH 1/2] swiotlb: range_needs_mapping should take a physical address.

[Ian Campbell]

The swiotlb_arch_range_needs_mapping() hook should take a physical
address rather than a virtual address in order to support highmem pages.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 arch/x86/kernel/pci-swiotlb_64.c |    2 +-
 include/linux/swiotlb.h          |    2 +-
 lib/swiotlb.c                    |   10 +++++-----
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/x86/kernel/pci-swiotlb_64.c b/arch/x86/kernel/pci-swiotlb_64.c
index 5e32c4f..34f12e9 100644
--- a/arch/x86/kernel/pci-swiotlb_64.c
+++ b/arch/x86/kernel/pci-swiotlb_64.c
@@ -33,7 +33,7 @@ phys_addr_t swiotlb_bus_to_phys(dma_addr_t baddr)
 	return baddr;
 }
 
-int __weak swiotlb_arch_range_needs_mapping(void *ptr, size_t size)
+int __weak swiotlb_arch_range_needs_mapping(phys_addr_t paddr, size_t size)
 {
 	return 0;
 }
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 493dc17..ac9ff54 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -31,7 +31,7 @@ extern dma_addr_t swiotlb_phys_to_bus(struct device *hwdev,
 				      phys_addr_t address);
 extern phys_addr_t swiotlb_bus_to_phys(dma_addr_t address);
 
-extern int swiotlb_arch_range_needs_mapping(void *ptr, size_t size);
+extern int swiotlb_arch_range_needs_mapping(phys_addr_t paddr, size_t size);
 
 extern void
 *swiotlb_alloc_coherent(struct device *hwdev, size_t size,
diff --git a/lib/swiotlb.c b/lib/swiotlb.c
index 30fe65e..31bae40 100644
--- a/lib/swiotlb.c
+++ b/lib/swiotlb.c
@@ -145,7 +145,7 @@ static void *swiotlb_bus_to_virt(dma_addr_t address)
 	return phys_to_virt(swiotlb_bus_to_phys(address));
 }
 
-int __weak swiotlb_arch_range_needs_mapping(void *ptr, size_t size)
+int __weak swiotlb_arch_range_needs_mapping(phys_addr_t paddr, size_t size)
 {
 	return 0;
 }
@@ -315,9 +315,9 @@ address_needs_mapping(struct device *hwdev, dma_addr_t addr, size_t size)
 	return !is_buffer_dma_capable(dma_get_mask(hwdev), addr, size);
 }
 
-static inline int range_needs_mapping(void *ptr, size_t size)
+static inline int range_needs_mapping(phys_addr_t paddr, size_t size)
 {
-	return swiotlb_force || swiotlb_arch_range_needs_mapping(ptr, size);
+	return swiotlb_force || swiotlb_arch_range_needs_mapping(paddr, size);
 }
 
 static int is_swiotlb_buffer(char *addr)
@@ -653,7 +653,7 @@ dma_addr_t swiotlb_map_page(struct device *dev, struct page *page,
 	 * buffering it.
 	 */
 	if (!address_needs_mapping(dev, dev_addr, size) &&
-	    !range_needs_mapping(ptr, size))
+	    !range_needs_mapping(virt_to_phys(ptr), size))
 		return dev_addr;
 
 	/*
@@ -804,7 +804,7 @@ swiotlb_map_sg_attrs(struct device *hwdev, struct scatterlist *sgl, int nelems,
 		void *addr = sg_virt(sg);
 		dma_addr_t dev_addr = swiotlb_virt_to_bus(hwdev, addr);
 
-		if (range_needs_mapping(addr, sg->length) ||
+		if (range_needs_mapping(sg_phys(sg), sg->length) ||
 		    address_needs_mapping(hwdev, dev_addr, sg->length)) {
 			void *map = map_single(hwdev, sg_phys(sg),
 					       sg->length, dir);
-- 
1.5.6.5

[PATCH 2/2] swiotlb: do not use sg_virt()

[Ian Campbell]

Scatterlists containing HighMem pages do not have a useful virtual
address. Use the physical address instead.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 lib/swiotlb.c |   14 +++++++-------
 1 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/lib/swiotlb.c b/lib/swiotlb.c
index 31bae40..32e2bd3 100644
--- a/lib/swiotlb.c
+++ b/lib/swiotlb.c
@@ -801,10 +801,10 @@ swiotlb_map_sg_attrs(struct device *hwdev, struct scatterlist *sgl, int nelems,
 	BUG_ON(dir == DMA_NONE);
 
 	for_each_sg(sgl, sg, nelems, i) {
-		void *addr = sg_virt(sg);
-		dma_addr_t dev_addr = swiotlb_virt_to_bus(hwdev, addr);
+		phys_addr_t paddr = sg_phys(sg);
+		dma_addr_t dev_addr = swiotlb_phys_to_bus(hwdev, paddr);
 
-		if (range_needs_mapping(sg_phys(sg), sg->length) ||
+		if (range_needs_mapping(paddr, sg->length) ||
 		    address_needs_mapping(hwdev, dev_addr, sg->length)) {
 			void *map = map_single(hwdev, sg_phys(sg),
 					       sg->length, dir);
@@ -848,11 +848,11 @@ swiotlb_unmap_sg_attrs(struct device *hwdev, struct scatterlist *sgl,
 	BUG_ON(dir == DMA_NONE);
 
 	for_each_sg(sgl, sg, nelems, i) {
-		if (sg->dma_address != swiotlb_virt_to_bus(hwdev, sg_virt(sg)))
+		if (sg->dma_address != swiotlb_phys_to_bus(hwdev, sg_phys(sg)))
 			unmap_single(hwdev, swiotlb_bus_to_virt(sg->dma_address),
 				     sg->dma_length, dir);
 		else if (dir == DMA_FROM_DEVICE)
-			dma_mark_clean(sg_virt(sg), sg->dma_length);
+			dma_mark_clean(swiotlb_bus_to_virt(sg->dma_address), sg->dma_length);
 	}
 }
 EXPORT_SYMBOL(swiotlb_unmap_sg_attrs);
@@ -882,11 +882,11 @@ swiotlb_sync_sg(struct device *hwdev, struct scatterlist *sgl,
 	BUG_ON(dir == DMA_NONE);
 
 	for_each_sg(sgl, sg, nelems, i) {
-		if (sg->dma_address != swiotlb_virt_to_bus(hwdev, sg_virt(sg)))
+		if (sg->dma_address != swiotlb_phys_to_bus(hwdev, sg_phys(sg)))
 			sync_single(hwdev, swiotlb_bus_to_virt(sg->dma_address),
 				    sg->dma_length, dir, target);
 		else if (dir == DMA_FROM_DEVICE)
-			dma_mark_clean(sg_virt(sg), sg->dma_length);
+			dma_mark_clean(swiotlb_bus_to_virt(sg->dma_address), sg->dma_length);
 	}
 }
 
-- 
1.5.6.5

Re: [PATCH 2/2] swiotlb: do not use sg_virt()

[FUJITA Tomonori]

On Fri,  9 Jan 2009 18:32:10 +0000
Ian Campbell <Ian.Campbell@citrix.com> wrote:

> Scatterlists containing HighMem pages do not have a useful virtual
> address. Use the physical address instead.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  lib/swiotlb.c |   14 +++++++-------
>  1 files changed, 7 insertions(+), 7 deletions(-)

Looks good.

Re: [PATCH 1/2] swiotlb: range_needs_mapping should take a physical address.

[FUJITA Tomonori]

On Fri,  9 Jan 2009 18:32:09 +0000
Ian Campbell <Ian.Campbell@citrix.com> wrote:

> The swiotlb_arch_range_needs_mapping() hook should take a physical
> address rather than a virtual address in order to support highmem pages.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  arch/x86/kernel/pci-swiotlb_64.c |    2 +-
>  include/linux/swiotlb.h          |    2 +-
>  lib/swiotlb.c                    |   10 +++++-----
>  3 files changed, 7 insertions(+), 7 deletions(-)

Yeah, using a cpu address here doesn't make sense. I wondered what you
were trying with a cpu address when reading your original patch.

Might be more clean to unify address_needs_mapping and
range_needs_mapping. I guess that I need to see what Xen wants to do
with this though.

Re: [PATCH 0/2] Re: swiotlb: remove duplicated #include

[Ingo Molnar]

* Ian Campbell <Ian.Campbell@citrix.com> wrote:

> On Fri, 2009-01-09 at 18:10 +0000, Ian Campbell wrote:
> 
> > Patch is against Jeremy's Xen patch queue which is based on a pre-Xmas
> > tip tree so fairly out of date, I hope it is somewhat useful though.
> 
> Here's a version again tip-latest, only compile tested though since my
> testing relies on the Xen dom0 patch queue.

Applied them to tip/core/iommu:

 961d7d0: swiotlb: do not use sg_virt()
 0b8698a: swiotlb: range_needs_mapping should take a physical address.

thanks Ian!

	Ingo

Re: [PATCH 0/2] Re: swiotlb: remove duplicated #include

[FUJITA Tomonori]

On Sun, 11 Jan 2009 04:55:27 +0100
Ingo Molnar <mingo@elte.hu> wrote:

> 
> * Ian Campbell <Ian.Campbell@citrix.com> wrote:
> 
> > On Fri, 2009-01-09 at 18:10 +0000, Ian Campbell wrote:
> > 
> > > Patch is against Jeremy's Xen patch queue which is based on a pre-Xmas
> > > tip tree so fairly out of date, I hope it is somewhat useful though.
> > 
> > Here's a version again tip-latest, only compile tested though since my
> > testing relies on the Xen dom0 patch queue.
> 
> Applied them to tip/core/iommu:
> 
>  961d7d0: swiotlb: do not use sg_virt()
>  0b8698a: swiotlb: range_needs_mapping should take a physical address.

I think that Xen camp wants these changes for 2.6.29. Are you trying
to push tip/core/iommu for 2.6.29?

Re: [PATCH 0/2] Re: swiotlb: remove duplicated #include

[Ingo Molnar]

* FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> wrote:

> On Sun, 11 Jan 2009 04:55:27 +0100
> Ingo Molnar <mingo@elte.hu> wrote:
> 
> > 
> > * Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > 
> > > On Fri, 2009-01-09 at 18:10 +0000, Ian Campbell wrote:
> > > 
> > > > Patch is against Jeremy's Xen patch queue which is based on a pre-Xmas
> > > > tip tree so fairly out of date, I hope it is somewhat useful though.
> > > 
> > > Here's a version again tip-latest, only compile tested though since my
> > > testing relies on the Xen dom0 patch queue.
> > 
> > Applied them to tip/core/iommu:
> > 
> >  961d7d0: swiotlb: do not use sg_virt()
> >  0b8698a: swiotlb: range_needs_mapping should take a physical address.
> 
> I think that Xen camp wants these changes for 2.6.29. Are you trying to 
> push tip/core/iommu for 2.6.29?

Yet unclear, depends on testing. Will probably wait for 2.6.30 though.

	Ingo

Re: [PATCH 0/2] Re: swiotlb: remove duplicated #include

[FUJITA Tomonori]

On Sun, 11 Jan 2009 05:04:28 +0100
Ingo Molnar <mingo@elte.hu> wrote:

> 
> * FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> wrote:
> 
> > On Sun, 11 Jan 2009 04:55:27 +0100
> > Ingo Molnar <mingo@elte.hu> wrote:
> > 
> > > 
> > > * Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > > 
> > > > On Fri, 2009-01-09 at 18:10 +0000, Ian Campbell wrote:
> > > > 
> > > > > Patch is against Jeremy's Xen patch queue which is based on a pre-Xmas
> > > > > tip tree so fairly out of date, I hope it is somewhat useful though.
> > > > 
> > > > Here's a version again tip-latest, only compile tested though since my
> > > > testing relies on the Xen dom0 patch queue.
> > > 
> > > Applied them to tip/core/iommu:
> > > 
> > >  961d7d0: swiotlb: do not use sg_virt()
> > >  0b8698a: swiotlb: range_needs_mapping should take a physical address.
> > 
> > I think that Xen camp wants these changes for 2.6.29. Are you trying to 
> > push tip/core/iommu for 2.6.29?
> 
> Yet unclear, depends on testing. Will probably wait for 2.6.30 though.

Thanks, I see. Probably, it will get tons of conflict due to the dma
API unification touching everywhere.


BTW, what happened to?

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


It's better to have these (especially Becky's work) in mainline now.

Re: [PATCH 0/2] Re: swiotlb: remove duplicated #include

[Ingo Molnar]

* FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> wrote:

> On Sun, 11 Jan 2009 05:04:28 +0100
> Ingo Molnar <mingo@elte.hu> wrote:
> 
> > 
> > * FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> wrote:
> > 
> > > On Sun, 11 Jan 2009 04:55:27 +0100
> > > Ingo Molnar <mingo@elte.hu> wrote:
> > > 
> > > > 
> > > > * Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > > > 
> > > > > On Fri, 2009-01-09 at 18:10 +0000, Ian Campbell wrote:
> > > > > 
> > > > > > Patch is against Jeremy's Xen patch queue which is based on a pre-Xmas
> > > > > > tip tree so fairly out of date, I hope it is somewhat useful though.
> > > > > 
> > > > > Here's a version again tip-latest, only compile tested though since my
> > > > > testing relies on the Xen dom0 patch queue.
> > > > 
> > > > Applied them to tip/core/iommu:
> > > > 
> > > >  961d7d0: swiotlb: do not use sg_virt()
> > > >  0b8698a: swiotlb: range_needs_mapping should take a physical address.
> > > 
> > > I think that Xen camp wants these changes for 2.6.29. Are you trying to 
> > > push tip/core/iommu for 2.6.29?
> > 
> > Yet unclear, depends on testing. Will probably wait for 2.6.30 though.
> 
> Thanks, I see. Probably, it will get tons of conflict due to the dma API 
> unification touching everywhere.
>
> BTW, what happened to?
> 
> http://marc.info/?l=linux-kernel&m=123125853906986&w=2

it's in -rc1.

	Ingo

Re: [PATCH 0/2] Re: swiotlb: remove duplicated #include

[FUJITA Tomonori]

On Sun, 11 Jan 2009 05:32:51 +0100
Ingo Molnar <mingo@elte.hu> wrote:

> 
> * FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> wrote:
> 
> > On Sun, 11 Jan 2009 05:04:28 +0100
> > Ingo Molnar <mingo@elte.hu> wrote:
> > 
> > > 
> > > * FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> wrote:
> > > 
> > > > On Sun, 11 Jan 2009 04:55:27 +0100
> > > > Ingo Molnar <mingo@elte.hu> wrote:
> > > > 
> > > > > 
> > > > > * Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > > > > 
> > > > > > On Fri, 2009-01-09 at 18:10 +0000, Ian Campbell wrote:
> > > > > > 
> > > > > > > Patch is against Jeremy's Xen patch queue which is based on a pre-Xmas
> > > > > > > tip tree so fairly out of date, I hope it is somewhat useful though.
> > > > > > 
> > > > > > Here's a version again tip-latest, only compile tested though since my
> > > > > > testing relies on the Xen dom0 patch queue.
> > > > > 
> > > > > Applied them to tip/core/iommu:
> > > > > 
> > > > >  961d7d0: swiotlb: do not use sg_virt()
> > > > >  0b8698a: swiotlb: range_needs_mapping should take a physical address.
> > > > 
> > > > I think that Xen camp wants these changes for 2.6.29. Are you trying to 
> > > > push tip/core/iommu for 2.6.29?
> > > 
> > > Yet unclear, depends on testing. Will probably wait for 2.6.30 though.
> > 
> > Thanks, I see. Probably, it will get tons of conflict due to the dma API 
> > unification touching everywhere.
> >
> > BTW, what happened to?
> > 
> > http://marc.info/?l=linux-kernel&m=123125853906986&w=2
> 
> it's in -rc1.

Duh, sorry about that. I missed it somehow.