Removed duplicated #include in lib/swiotlb.c.
Signed-off-by: Huang Weiyi <[email protected]>
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>
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 <[email protected]>
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
* Jesper Juhl <[email protected]> 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
On Sun, 4 Jan 2009 12:25:43 +0100
Ingo Molnar <[email protected]> wrote:
>
> * Jesper Juhl <[email protected]> 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?
* FUJITA Tomonori <[email protected]> wrote:
> On Sun, 4 Jan 2009 12:25:43 +0100
> Ingo Molnar <[email protected]> wrote:
>
> >
> > * Jesper Juhl <[email protected]> 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
On Sun, 4 Jan 2009 13:19:14 +0100
Ingo Molnar <[email protected]> wrote:
>
> * FUJITA Tomonori <[email protected]> wrote:
>
> > On Sun, 4 Jan 2009 12:25:43 +0100
> > Ingo Molnar <[email protected]> wrote:
> >
> > >
> > > * Jesper Juhl <[email protected]> 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.
* FUJITA Tomonori <[email protected]> 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
Ingo Molnar wrote:
> * FUJITA Tomonori <[email protected]> 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
On Mon, 05 Jan 2009 09:48:36 +1100
Jeremy Fitzhardinge <[email protected]> wrote:
> Ingo Molnar wrote:
> > * FUJITA Tomonori <[email protected]> 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.
* Jeremy Fitzhardinge <[email protected]> wrote:
> Ingo Molnar wrote:
>> * FUJITA Tomonori <[email protected]> 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
On Mon, 2009-01-05 at 09:48 +1100, Jeremy Fitzhardinge wrote:
> Ingo Molnar wrote:
> > * FUJITA Tomonori <[email protected]> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
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 <[email protected]> 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
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 <[email protected]> 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 <[email protected]>
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);
}
}
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.
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 <[email protected]>
---
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
Scatterlists containing HighMem pages do not have a useful virtual
address. Use the physical address instead.
Signed-off-by: Ian Campbell <[email protected]>
---
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
* Ian Campbell <[email protected]> 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
On Fri, 9 Jan 2009 18:32:09 +0000
Ian Campbell <[email protected]> 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 <[email protected]>
> ---
> 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.
On Fri, 9 Jan 2009 18:32:10 +0000
Ian Campbell <[email protected]> wrote:
> Scatterlists containing HighMem pages do not have a useful virtual
> address. Use the physical address instead.
>
> Signed-off-by: Ian Campbell <[email protected]>
> ---
> lib/swiotlb.c | 14 +++++++-------
> 1 files changed, 7 insertions(+), 7 deletions(-)
Looks good.
On Sun, 11 Jan 2009 04:55:27 +0100
Ingo Molnar <[email protected]> wrote:
>
> * Ian Campbell <[email protected]> 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?
* FUJITA Tomonori <[email protected]> wrote:
> On Sun, 11 Jan 2009 04:55:27 +0100
> Ingo Molnar <[email protected]> wrote:
>
> >
> > * Ian Campbell <[email protected]> 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
On Sun, 11 Jan 2009 05:04:28 +0100
Ingo Molnar <[email protected]> wrote:
>
> * FUJITA Tomonori <[email protected]> wrote:
>
> > On Sun, 11 Jan 2009 04:55:27 +0100
> > Ingo Molnar <[email protected]> wrote:
> >
> > >
> > > * Ian Campbell <[email protected]> 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.
* FUJITA Tomonori <[email protected]> wrote:
> On Sun, 11 Jan 2009 05:04:28 +0100
> Ingo Molnar <[email protected]> wrote:
>
> >
> > * FUJITA Tomonori <[email protected]> wrote:
> >
> > > On Sun, 11 Jan 2009 04:55:27 +0100
> > > Ingo Molnar <[email protected]> wrote:
> > >
> > > >
> > > > * Ian Campbell <[email protected]> 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
On Sun, 11 Jan 2009 05:32:51 +0100
Ingo Molnar <[email protected]> wrote:
>
> * FUJITA Tomonori <[email protected]> wrote:
>
> > On Sun, 11 Jan 2009 05:04:28 +0100
> > Ingo Molnar <[email protected]> wrote:
> >
> > >
> > > * FUJITA Tomonori <[email protected]> wrote:
> > >
> > > > On Sun, 11 Jan 2009 04:55:27 +0100
> > > > Ingo Molnar <[email protected]> wrote:
> > > >
> > > > >
> > > > > * Ian Campbell <[email protected]> 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.