Re: [PATCH 09/33] x86-64: update iommu/dma mapping functions to sg helpers
On Tue, Jul 17, 2007 at 01:05:03PM +0200, Jens Axboe wrote: > > FYI, here's the Calgary diff on top of the outstanding Calgary > > changes. > > When are these bits being merged into mainline? I'll hang on to this > version for helping me rebase the arch bits of chained sglists once > that happens. I sincerely hope they'll make 2.6.23 but Andi appears to have fallen into a black hole. Cheers, Muli - 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/
Re: [PATCH 09/33] x86-64: update iommu/dma mapping functions to sg helpers
On Tue, Jul 17 2007, Muli Ben-Yehuda wrote: > On Mon, Jul 16, 2007 at 11:47:23AM +0200, Jens Axboe wrote: > > > This prepares x86-64 for sg chaining support. > > > > Additional improvements/fixups for pci-gart from > > Benny Halevy <[EMAIL PROTECTED]> > > > > Cc: [EMAIL PROTECTED] > > Signed-off-by: Jens Axboe <[EMAIL PROTECTED]> > > --- > > arch/x86_64/kernel/pci-calgary.c | 25 -- > > arch/x86_64/kernel/pci-gart.c| 63 > > - > > arch/x86_64/kernel/pci-nommu.c |5 ++- > > Calgary and nommu bits are: > > Acked-by: Muli Ben-Yehuda <[EMAIL PROTECTED]> Great, thanks! > FYI, here's the Calgary diff on top of the outstanding Calgary > changes. When are these bits being merged into mainline? I'll hang on to this version for helping me rebase the arch bits of chained sglists once that happens. -- Jens Axboe - 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/
Re: [PATCH 09/33] x86-64: update iommu/dma mapping functions to sg helpers
On Mon, Jul 16, 2007 at 11:47:23AM +0200, Jens Axboe wrote:
> This prepares x86-64 for sg chaining support.
>
> Additional improvements/fixups for pci-gart from
> Benny Halevy <[EMAIL PROTECTED]>
>
> Cc: [EMAIL PROTECTED]
> Signed-off-by: Jens Axboe <[EMAIL PROTECTED]>
> ---
> arch/x86_64/kernel/pci-calgary.c | 25 --
> arch/x86_64/kernel/pci-gart.c| 63 -
> arch/x86_64/kernel/pci-nommu.c |5 ++-
Calgary and nommu bits are:
Acked-by: Muli Ben-Yehuda <[EMAIL PROTECTED]>
FYI, here's the Calgary diff on top of the outstanding Calgary
changes.
diff -r 8642809f9e33 arch/x86_64/kernel/pci-calgary.c
--- a/arch/x86_64/kernel/pci-calgary.c Mon Jul 16 09:38:14 2007 +0300
+++ b/arch/x86_64/kernel/pci-calgary.c Tue Jul 17 13:33:24 2007 +0300
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -387,31 +388,32 @@ static void calgary_unmap_sg(struct devi
struct scatterlist *sglist, int nelems, int direction)
{
struct iommu_table *tbl = find_iommu_table(dev);
+ struct scatterlist *s;
+ int i;
if (!translate_phb(to_pci_dev(dev)))
return;
- while (nelems--) {
+ for_each_sg(sglist, s, nelems, i) {
unsigned int npages;
- dma_addr_t dma = sglist->dma_address;
- unsigned int dmalen = sglist->dma_length;
+ dma_addr_t dma = s->dma_address;
+ unsigned int dmalen = s->dma_length;
if (dmalen == 0)
break;
npages = num_dma_pages(dma, dmalen);
iommu_free(tbl, dma, npages);
- sglist++;
}
}
static int calgary_nontranslate_map_sg(struct device* dev,
struct scatterlist *sg, int nelems, int direction)
{
+ struct scatterlist *s;
int i;
- for (i = 0; i < nelems; i++ ) {
- struct scatterlist *s = [i];
+ for_each_sg(sg, s, nelems, i) {
BUG_ON(!s->page);
s->dma_address = virt_to_bus(page_address(s->page) +s->offset);
s->dma_length = s->length;
@@ -423,6 +425,7 @@ static int calgary_map_sg(struct device
int nelems, int direction)
{
struct iommu_table *tbl = find_iommu_table(dev);
+ struct scatterlist *s;
unsigned long vaddr;
unsigned int npages;
unsigned long entry;
@@ -431,8 +434,7 @@ static int calgary_map_sg(struct device
if (!translate_phb(to_pci_dev(dev)))
return calgary_nontranslate_map_sg(dev, sg, nelems, direction);
- for (i = 0; i < nelems; i++ ) {
- struct scatterlist *s = [i];
+ for_each_sg(sg, s, nelems, i) {
BUG_ON(!s->page);
vaddr = (unsigned long)page_address(s->page) + s->offset;
@@ -457,9 +459,9 @@ static int calgary_map_sg(struct device
return nelems;
error:
calgary_unmap_sg(dev, sg, nelems, direction);
- for (i = 0; i < nelems; i++) {
- sg[i].dma_address = bad_dma_address;
- sg[i].dma_length = 0;
+ for_each_sg(sg, s, nelems, i) {
+ s->dma_address = bad_dma_address;
+ s->dma_length = 0;
}
return 0;
}
-
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/
Re: [PATCH 09/33] x86-64: update iommu/dma mapping functions to sg helpers
On Tue, Jul 17, 2007 at 10:51:23AM +0200, Jens Axboe wrote: > On Tue, Jul 17 2007, Muli Ben-Yehuda wrote: > > On Tue, Jul 17, 2007 at 09:38:59AM +0200, Jens Axboe wrote: > > > > > On Tue, Jul 17 2007, Muli Ben-Yehuda wrote: > > > > > > The Xen and Calgary bits are mutually exclusive, so hopefully (a) > > > > will not be held up on account of the Xen merge (or for any other > > > > reason... CalIOC2 machines which are out there won't boot without > > > > it if CONFIG_CALGARY_IOMMU is enabled). > > > > > > Do you have any comments for the patch to calgary (the mail you are > > > replying to)? > > > > It looks ok, I just didn't want to ACK it before testing (I'm paranoid > > that way). > > That's certainly understandable! Can you mail me an ack once you've had > a chance to test it? Yep, taking it for a spin now. Cheers, Muli - 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/
Re: [PATCH 09/33] x86-64: update iommu/dma mapping functions to sg helpers
On Tue, Jul 17 2007, Muli Ben-Yehuda wrote: > On Tue, Jul 17, 2007 at 09:38:59AM +0200, Jens Axboe wrote: > > > On Tue, Jul 17 2007, Muli Ben-Yehuda wrote: > > > > The Xen and Calgary bits are mutually exclusive, so hopefully (a) > > > will not be held up on account of the Xen merge (or for any other > > > reason... CalIOC2 machines which are out there won't boot without > > > it if CONFIG_CALGARY_IOMMU is enabled). > > > > Do you have any comments for the patch to calgary (the mail you are > > replying to)? > > It looks ok, I just didn't want to ACK it before testing (I'm paranoid > that way). That's certainly understandable! Can you mail me an ack once you've had a chance to test it? -- Jens Axboe - 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/
Re: [PATCH 09/33] x86-64: update iommu/dma mapping functions to sg helpers
On Tue, Jul 17, 2007 at 09:38:59AM +0200, Jens Axboe wrote: > On Tue, Jul 17 2007, Muli Ben-Yehuda wrote: > > The Xen and Calgary bits are mutually exclusive, so hopefully (a) > > will not be held up on account of the Xen merge (or for any other > > reason... CalIOC2 machines which are out there won't boot without > > it if CONFIG_CALGARY_IOMMU is enabled). > > Do you have any comments for the patch to calgary (the mail you are > replying to)? It looks ok, I just didn't want to ACK it before testing (I'm paranoid that way). Cheers, Muli - 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/
Re: [PATCH 09/33] x86-64: update iommu/dma mapping functions to sg helpers
On Tue, Jul 17 2007, Jens Axboe wrote: > On Mon, Jul 16 2007, Andrew Morton wrote: > > On Mon, 16 Jul 2007 22:10:03 +0200 > > Jens Axboe <[EMAIL PROTECTED]> wrote: > > > > > On Mon, Jul 16 2007, Andrew Morton wrote: > > > > On Mon, 16 Jul 2007 11:47:23 +0200 > > > > Jens Axboe <[EMAIL PROTECTED]> wrote: > > > > > > > > > This prepares x86-64 for sg chaining support. > > > > > > > > > > Additional improvements/fixups for pci-gart from > > > > > Benny Halevy <[EMAIL PROTECTED]> > > > > > > > > > > Cc: [EMAIL PROTECTED] > > > > > Signed-off-by: Jens Axboe <[EMAIL PROTECTED]> > > > > > --- > > > > > arch/x86_64/kernel/pci-calgary.c | 25 -- > > > > > arch/x86_64/kernel/pci-gart.c| 63 > > > > > - > > > > > arch/x86_64/kernel/pci-nommu.c |5 ++- > > > > > 3 files changed, 51 insertions(+), 42 deletions(-) > > > > > > > > This causes fairly extensive destruction of 2.6.23 changes which are > > > > pending in Andi's tree. > > > > > > > > I shall drop the block tree until a) Andi has merged the pending Calgary > > > > changes and b) the block tree has been fixed up to account for those > > > > (and > > > > other) changes. > > > > > > > > Really, this was the perfectly worst time possible to go tromping all > > > > over > > > > everyone else's trees. > > > > > > Well, that's a bit hard for me to know, all I can do is push my stuff to > > > for-akpm so that it gets -mm exposure. If I don't, then you are yelling > > > at me as well :-) > > > > It is to be expected that there will be conflicts when making large-scale > > changes like this while there is 25MB of unmerged diff sitting out in 50 > > different trees. Doing it around the -rc1 time would be better. > > > > Even better would be not doing it at all: add the necessary stuff into the > > block core and then send the followup work to the relevant maintainers. ie: > > standard practice. > > I'll do that. Most of the stuff is trivial, but the x86-64 iommu changes > are probably the most tricky and invasive of them all. OK, this is what I did: Split the set into 3, in the following order: CORE -> DRIVERS -> ARCH So that's 3 branches, core is based off master, drivers off core, and arch off drivers. I'll push core+drivers into #for-akpm for testing, then the arch bits will stay undisturbed until acked by maintainers. -- Jens Axboe - 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/
Re: [PATCH 09/33] x86-64: update iommu/dma mapping functions to sg helpers
On Tue, Jul 17 2007, Muli Ben-Yehuda wrote: > On Mon, Jul 16, 2007 at 01:34:27PM -0700, Andrew Morton wrote: > > > > I'll keep rebasing sglist and the other branches I pull into for-akpm, > > > so you can just re-enable the for-akpm pull when the a) is true. > > > > Andi's tree is very out of date and is about to be damaged (to what > > extent I don't yet know) by a xen merge. I don't know if a) is > > going to happen. > > The Xen and Calgary bits are mutually exclusive, so hopefully (a) will > not be held up on account of the Xen merge (or for any other > reason... CalIOC2 machines which are out there won't boot without it > if CONFIG_CALGARY_IOMMU is enabled). Do you have any comments for the patch to calgary (the mail you are replying to)? -- Jens Axboe - 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/
Re: [PATCH 09/33] x86-64: update iommu/dma mapping functions to sg helpers
On Mon, Jul 16 2007, Andrew Morton wrote: > On Mon, 16 Jul 2007 22:10:03 +0200 > Jens Axboe <[EMAIL PROTECTED]> wrote: > > > On Mon, Jul 16 2007, Andrew Morton wrote: > > > On Mon, 16 Jul 2007 11:47:23 +0200 > > > Jens Axboe <[EMAIL PROTECTED]> wrote: > > > > > > > This prepares x86-64 for sg chaining support. > > > > > > > > Additional improvements/fixups for pci-gart from > > > > Benny Halevy <[EMAIL PROTECTED]> > > > > > > > > Cc: [EMAIL PROTECTED] > > > > Signed-off-by: Jens Axboe <[EMAIL PROTECTED]> > > > > --- > > > > arch/x86_64/kernel/pci-calgary.c | 25 -- > > > > arch/x86_64/kernel/pci-gart.c| 63 > > > > - > > > > arch/x86_64/kernel/pci-nommu.c |5 ++- > > > > 3 files changed, 51 insertions(+), 42 deletions(-) > > > > > > This causes fairly extensive destruction of 2.6.23 changes which are > > > pending in Andi's tree. > > > > > > I shall drop the block tree until a) Andi has merged the pending Calgary > > > changes and b) the block tree has been fixed up to account for those (and > > > other) changes. > > > > > > Really, this was the perfectly worst time possible to go tromping all over > > > everyone else's trees. > > > > Well, that's a bit hard for me to know, all I can do is push my stuff to > > for-akpm so that it gets -mm exposure. If I don't, then you are yelling > > at me as well :-) > > It is to be expected that there will be conflicts when making large-scale > changes like this while there is 25MB of unmerged diff sitting out in 50 > different trees. Doing it around the -rc1 time would be better. > > Even better would be not doing it at all: add the necessary stuff into the > block core and then send the followup work to the relevant maintainers. ie: > standard practice. I'll do that. Most of the stuff is trivial, but the x86-64 iommu changes are probably the most tricky and invasive of them all. > > I'll keep rebasing sglist and the other branches I pull into for-akpm, > > so you can just re-enable the for-akpm pull when the a) is true. > > Andi's tree is very out of date and is about to be damaged (to what extent > I don't yet know) by a xen merge. I don't know if a) is going to happen. > > > Things are more than usually messy this time around. Seems so :) -- Jens Axboe - 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/
Re: [PATCH 09/33] x86-64: update iommu/dma mapping functions to sg helpers
On Mon, Jul 16 2007, Andrew Morton wrote: On Mon, 16 Jul 2007 22:10:03 +0200 Jens Axboe [EMAIL PROTECTED] wrote: On Mon, Jul 16 2007, Andrew Morton wrote: On Mon, 16 Jul 2007 11:47:23 +0200 Jens Axboe [EMAIL PROTECTED] wrote: This prepares x86-64 for sg chaining support. Additional improvements/fixups for pci-gart from Benny Halevy [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Signed-off-by: Jens Axboe [EMAIL PROTECTED] --- arch/x86_64/kernel/pci-calgary.c | 25 -- arch/x86_64/kernel/pci-gart.c| 63 - arch/x86_64/kernel/pci-nommu.c |5 ++- 3 files changed, 51 insertions(+), 42 deletions(-) This causes fairly extensive destruction of 2.6.23 changes which are pending in Andi's tree. I shall drop the block tree until a) Andi has merged the pending Calgary changes and b) the block tree has been fixed up to account for those (and other) changes. Really, this was the perfectly worst time possible to go tromping all over everyone else's trees. Well, that's a bit hard for me to know, all I can do is push my stuff to for-akpm so that it gets -mm exposure. If I don't, then you are yelling at me as well :-) It is to be expected that there will be conflicts when making large-scale changes like this while there is 25MB of unmerged diff sitting out in 50 different trees. Doing it around the -rc1 time would be better. Even better would be not doing it at all: add the necessary stuff into the block core and then send the followup work to the relevant maintainers. ie: standard practice. I'll do that. Most of the stuff is trivial, but the x86-64 iommu changes are probably the most tricky and invasive of them all. I'll keep rebasing sglist and the other branches I pull into for-akpm, so you can just re-enable the for-akpm pull when the a) is true. Andi's tree is very out of date and is about to be damaged (to what extent I don't yet know) by a xen merge. I don't know if a) is going to happen. Things are more than usually messy this time around. Seems so :) -- Jens Axboe - 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/
Re: [PATCH 09/33] x86-64: update iommu/dma mapping functions to sg helpers
On Tue, Jul 17 2007, Muli Ben-Yehuda wrote: On Mon, Jul 16, 2007 at 01:34:27PM -0700, Andrew Morton wrote: I'll keep rebasing sglist and the other branches I pull into for-akpm, so you can just re-enable the for-akpm pull when the a) is true. Andi's tree is very out of date and is about to be damaged (to what extent I don't yet know) by a xen merge. I don't know if a) is going to happen. The Xen and Calgary bits are mutually exclusive, so hopefully (a) will not be held up on account of the Xen merge (or for any other reason... CalIOC2 machines which are out there won't boot without it if CONFIG_CALGARY_IOMMU is enabled). Do you have any comments for the patch to calgary (the mail you are replying to)? -- Jens Axboe - 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/
Re: [PATCH 09/33] x86-64: update iommu/dma mapping functions to sg helpers
On Tue, Jul 17 2007, Jens Axboe wrote: On Mon, Jul 16 2007, Andrew Morton wrote: On Mon, 16 Jul 2007 22:10:03 +0200 Jens Axboe [EMAIL PROTECTED] wrote: On Mon, Jul 16 2007, Andrew Morton wrote: On Mon, 16 Jul 2007 11:47:23 +0200 Jens Axboe [EMAIL PROTECTED] wrote: This prepares x86-64 for sg chaining support. Additional improvements/fixups for pci-gart from Benny Halevy [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Signed-off-by: Jens Axboe [EMAIL PROTECTED] --- arch/x86_64/kernel/pci-calgary.c | 25 -- arch/x86_64/kernel/pci-gart.c| 63 - arch/x86_64/kernel/pci-nommu.c |5 ++- 3 files changed, 51 insertions(+), 42 deletions(-) This causes fairly extensive destruction of 2.6.23 changes which are pending in Andi's tree. I shall drop the block tree until a) Andi has merged the pending Calgary changes and b) the block tree has been fixed up to account for those (and other) changes. Really, this was the perfectly worst time possible to go tromping all over everyone else's trees. Well, that's a bit hard for me to know, all I can do is push my stuff to for-akpm so that it gets -mm exposure. If I don't, then you are yelling at me as well :-) It is to be expected that there will be conflicts when making large-scale changes like this while there is 25MB of unmerged diff sitting out in 50 different trees. Doing it around the -rc1 time would be better. Even better would be not doing it at all: add the necessary stuff into the block core and then send the followup work to the relevant maintainers. ie: standard practice. I'll do that. Most of the stuff is trivial, but the x86-64 iommu changes are probably the most tricky and invasive of them all. OK, this is what I did: Split the set into 3, in the following order: CORE - DRIVERS - ARCH So that's 3 branches, core is based off master, drivers off core, and arch off drivers. I'll push core+drivers into #for-akpm for testing, then the arch bits will stay undisturbed until acked by maintainers. -- Jens Axboe - 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/
Re: [PATCH 09/33] x86-64: update iommu/dma mapping functions to sg helpers
On Tue, Jul 17, 2007 at 09:38:59AM +0200, Jens Axboe wrote: On Tue, Jul 17 2007, Muli Ben-Yehuda wrote: The Xen and Calgary bits are mutually exclusive, so hopefully (a) will not be held up on account of the Xen merge (or for any other reason... CalIOC2 machines which are out there won't boot without it if CONFIG_CALGARY_IOMMU is enabled). Do you have any comments for the patch to calgary (the mail you are replying to)? It looks ok, I just didn't want to ACK it before testing (I'm paranoid that way). Cheers, Muli - 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/
Re: [PATCH 09/33] x86-64: update iommu/dma mapping functions to sg helpers
On Tue, Jul 17 2007, Muli Ben-Yehuda wrote: On Tue, Jul 17, 2007 at 09:38:59AM +0200, Jens Axboe wrote: On Tue, Jul 17 2007, Muli Ben-Yehuda wrote: The Xen and Calgary bits are mutually exclusive, so hopefully (a) will not be held up on account of the Xen merge (or for any other reason... CalIOC2 machines which are out there won't boot without it if CONFIG_CALGARY_IOMMU is enabled). Do you have any comments for the patch to calgary (the mail you are replying to)? It looks ok, I just didn't want to ACK it before testing (I'm paranoid that way). That's certainly understandable! Can you mail me an ack once you've had a chance to test it? -- Jens Axboe - 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/
Re: [PATCH 09/33] x86-64: update iommu/dma mapping functions to sg helpers
On Tue, Jul 17, 2007 at 10:51:23AM +0200, Jens Axboe wrote: On Tue, Jul 17 2007, Muli Ben-Yehuda wrote: On Tue, Jul 17, 2007 at 09:38:59AM +0200, Jens Axboe wrote: On Tue, Jul 17 2007, Muli Ben-Yehuda wrote: The Xen and Calgary bits are mutually exclusive, so hopefully (a) will not be held up on account of the Xen merge (or for any other reason... CalIOC2 machines which are out there won't boot without it if CONFIG_CALGARY_IOMMU is enabled). Do you have any comments for the patch to calgary (the mail you are replying to)? It looks ok, I just didn't want to ACK it before testing (I'm paranoid that way). That's certainly understandable! Can you mail me an ack once you've had a chance to test it? Yep, taking it for a spin now. Cheers, Muli - 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/
Re: [PATCH 09/33] x86-64: update iommu/dma mapping functions to sg helpers
On Mon, Jul 16, 2007 at 11:47:23AM +0200, Jens Axboe wrote:
This prepares x86-64 for sg chaining support.
Additional improvements/fixups for pci-gart from
Benny Halevy [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Signed-off-by: Jens Axboe [EMAIL PROTECTED]
---
arch/x86_64/kernel/pci-calgary.c | 25 --
arch/x86_64/kernel/pci-gart.c| 63 -
arch/x86_64/kernel/pci-nommu.c |5 ++-
Calgary and nommu bits are:
Acked-by: Muli Ben-Yehuda [EMAIL PROTECTED]
FYI, here's the Calgary diff on top of the outstanding Calgary
changes.
diff -r 8642809f9e33 arch/x86_64/kernel/pci-calgary.c
--- a/arch/x86_64/kernel/pci-calgary.c Mon Jul 16 09:38:14 2007 +0300
+++ b/arch/x86_64/kernel/pci-calgary.c Tue Jul 17 13:33:24 2007 +0300
@@ -35,6 +35,7 @@
#include linux/pci_ids.h
#include linux/pci.h
#include linux/delay.h
+#include linux/scatterlist.h
#include asm/proto.h
#include asm/calgary.h
#include asm/tce.h
@@ -387,31 +388,32 @@ static void calgary_unmap_sg(struct devi
struct scatterlist *sglist, int nelems, int direction)
{
struct iommu_table *tbl = find_iommu_table(dev);
+ struct scatterlist *s;
+ int i;
if (!translate_phb(to_pci_dev(dev)))
return;
- while (nelems--) {
+ for_each_sg(sglist, s, nelems, i) {
unsigned int npages;
- dma_addr_t dma = sglist-dma_address;
- unsigned int dmalen = sglist-dma_length;
+ dma_addr_t dma = s-dma_address;
+ unsigned int dmalen = s-dma_length;
if (dmalen == 0)
break;
npages = num_dma_pages(dma, dmalen);
iommu_free(tbl, dma, npages);
- sglist++;
}
}
static int calgary_nontranslate_map_sg(struct device* dev,
struct scatterlist *sg, int nelems, int direction)
{
+ struct scatterlist *s;
int i;
- for (i = 0; i nelems; i++ ) {
- struct scatterlist *s = sg[i];
+ for_each_sg(sg, s, nelems, i) {
BUG_ON(!s-page);
s-dma_address = virt_to_bus(page_address(s-page) +s-offset);
s-dma_length = s-length;
@@ -423,6 +425,7 @@ static int calgary_map_sg(struct device
int nelems, int direction)
{
struct iommu_table *tbl = find_iommu_table(dev);
+ struct scatterlist *s;
unsigned long vaddr;
unsigned int npages;
unsigned long entry;
@@ -431,8 +434,7 @@ static int calgary_map_sg(struct device
if (!translate_phb(to_pci_dev(dev)))
return calgary_nontranslate_map_sg(dev, sg, nelems, direction);
- for (i = 0; i nelems; i++ ) {
- struct scatterlist *s = sg[i];
+ for_each_sg(sg, s, nelems, i) {
BUG_ON(!s-page);
vaddr = (unsigned long)page_address(s-page) + s-offset;
@@ -457,9 +459,9 @@ static int calgary_map_sg(struct device
return nelems;
error:
calgary_unmap_sg(dev, sg, nelems, direction);
- for (i = 0; i nelems; i++) {
- sg[i].dma_address = bad_dma_address;
- sg[i].dma_length = 0;
+ for_each_sg(sg, s, nelems, i) {
+ s-dma_address = bad_dma_address;
+ s-dma_length = 0;
}
return 0;
}
-
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/
Re: [PATCH 09/33] x86-64: update iommu/dma mapping functions to sg helpers
On Tue, Jul 17 2007, Muli Ben-Yehuda wrote: On Mon, Jul 16, 2007 at 11:47:23AM +0200, Jens Axboe wrote: This prepares x86-64 for sg chaining support. Additional improvements/fixups for pci-gart from Benny Halevy [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Signed-off-by: Jens Axboe [EMAIL PROTECTED] --- arch/x86_64/kernel/pci-calgary.c | 25 -- arch/x86_64/kernel/pci-gart.c| 63 - arch/x86_64/kernel/pci-nommu.c |5 ++- Calgary and nommu bits are: Acked-by: Muli Ben-Yehuda [EMAIL PROTECTED] Great, thanks! FYI, here's the Calgary diff on top of the outstanding Calgary changes. When are these bits being merged into mainline? I'll hang on to this version for helping me rebase the arch bits of chained sglists once that happens. -- Jens Axboe - 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/
Re: [PATCH 09/33] x86-64: update iommu/dma mapping functions to sg helpers
On Tue, Jul 17, 2007 at 01:05:03PM +0200, Jens Axboe wrote: FYI, here's the Calgary diff on top of the outstanding Calgary changes. When are these bits being merged into mainline? I'll hang on to this version for helping me rebase the arch bits of chained sglists once that happens. I sincerely hope they'll make 2.6.23 but Andi appears to have fallen into a black hole. Cheers, Muli - 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/
Re: [PATCH 09/33] x86-64: update iommu/dma mapping functions to sg helpers
On Mon, Jul 16, 2007 at 01:34:27PM -0700, Andrew Morton wrote: > > I'll keep rebasing sglist and the other branches I pull into for-akpm, > > so you can just re-enable the for-akpm pull when the a) is true. > > Andi's tree is very out of date and is about to be damaged (to what > extent I don't yet know) by a xen merge. I don't know if a) is > going to happen. The Xen and Calgary bits are mutually exclusive, so hopefully (a) will not be held up on account of the Xen merge (or for any other reason... CalIOC2 machines which are out there won't boot without it if CONFIG_CALGARY_IOMMU is enabled). Cheers, Muli - 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/
Re: [PATCH 09/33] x86-64: update iommu/dma mapping functions to sg helpers
On Mon, 16 Jul 2007 22:10:03 +0200 Jens Axboe <[EMAIL PROTECTED]> wrote: > On Mon, Jul 16 2007, Andrew Morton wrote: > > On Mon, 16 Jul 2007 11:47:23 +0200 > > Jens Axboe <[EMAIL PROTECTED]> wrote: > > > > > This prepares x86-64 for sg chaining support. > > > > > > Additional improvements/fixups for pci-gart from > > > Benny Halevy <[EMAIL PROTECTED]> > > > > > > Cc: [EMAIL PROTECTED] > > > Signed-off-by: Jens Axboe <[EMAIL PROTECTED]> > > > --- > > > arch/x86_64/kernel/pci-calgary.c | 25 -- > > > arch/x86_64/kernel/pci-gart.c| 63 > > > - > > > arch/x86_64/kernel/pci-nommu.c |5 ++- > > > 3 files changed, 51 insertions(+), 42 deletions(-) > > > > This causes fairly extensive destruction of 2.6.23 changes which are > > pending in Andi's tree. > > > > I shall drop the block tree until a) Andi has merged the pending Calgary > > changes and b) the block tree has been fixed up to account for those (and > > other) changes. > > > > Really, this was the perfectly worst time possible to go tromping all over > > everyone else's trees. > > Well, that's a bit hard for me to know, all I can do is push my stuff to > for-akpm so that it gets -mm exposure. If I don't, then you are yelling > at me as well :-) It is to be expected that there will be conflicts when making large-scale changes like this while there is 25MB of unmerged diff sitting out in 50 different trees. Doing it around the -rc1 time would be better. Even better would be not doing it at all: add the necessary stuff into the block core and then send the followup work to the relevant maintainers. ie: standard practice. > I'll keep rebasing sglist and the other branches I pull into for-akpm, > so you can just re-enable the for-akpm pull when the a) is true. Andi's tree is very out of date and is about to be damaged (to what extent I don't yet know) by a xen merge. I don't know if a) is going to happen. Things are more than usually messy this time around. - 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/
Re: [PATCH 09/33] x86-64: update iommu/dma mapping functions to sg helpers
On Mon, Jul 16 2007, Andrew Morton wrote: > On Mon, 16 Jul 2007 11:47:23 +0200 > Jens Axboe <[EMAIL PROTECTED]> wrote: > > > This prepares x86-64 for sg chaining support. > > > > Additional improvements/fixups for pci-gart from > > Benny Halevy <[EMAIL PROTECTED]> > > > > Cc: [EMAIL PROTECTED] > > Signed-off-by: Jens Axboe <[EMAIL PROTECTED]> > > --- > > arch/x86_64/kernel/pci-calgary.c | 25 -- > > arch/x86_64/kernel/pci-gart.c| 63 > > - > > arch/x86_64/kernel/pci-nommu.c |5 ++- > > 3 files changed, 51 insertions(+), 42 deletions(-) > > This causes fairly extensive destruction of 2.6.23 changes which are > pending in Andi's tree. > > I shall drop the block tree until a) Andi has merged the pending Calgary > changes and b) the block tree has been fixed up to account for those (and > other) changes. > > Really, this was the perfectly worst time possible to go tromping all over > everyone else's trees. Well, that's a bit hard for me to know, all I can do is push my stuff to for-akpm so that it gets -mm exposure. If I don't, then you are yelling at me as well :-) I'll keep rebasing sglist and the other branches I pull into for-akpm, so you can just re-enable the for-akpm pull when the a) is true. -- Jens Axboe - 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/
Re: [PATCH 09/33] x86-64: update iommu/dma mapping functions to sg helpers
On Mon, 16 Jul 2007 11:47:23 +0200 Jens Axboe <[EMAIL PROTECTED]> wrote: > This prepares x86-64 for sg chaining support. > > Additional improvements/fixups for pci-gart from > Benny Halevy <[EMAIL PROTECTED]> > > Cc: [EMAIL PROTECTED] > Signed-off-by: Jens Axboe <[EMAIL PROTECTED]> > --- > arch/x86_64/kernel/pci-calgary.c | 25 -- > arch/x86_64/kernel/pci-gart.c| 63 - > arch/x86_64/kernel/pci-nommu.c |5 ++- > 3 files changed, 51 insertions(+), 42 deletions(-) This causes fairly extensive destruction of 2.6.23 changes which are pending in Andi's tree. I shall drop the block tree until a) Andi has merged the pending Calgary changes and b) the block tree has been fixed up to account for those (and other) changes. Really, this was the perfectly worst time possible to go tromping all over everyone else's trees. - 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/
[PATCH 09/33] x86-64: update iommu/dma mapping functions to sg helpers
This prepares x86-64 for sg chaining support.
Additional improvements/fixups for pci-gart from
Benny Halevy <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Signed-off-by: Jens Axboe <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/pci-calgary.c | 25 --
arch/x86_64/kernel/pci-gart.c| 63 -
arch/x86_64/kernel/pci-nommu.c |5 ++-
3 files changed, 51 insertions(+), 42 deletions(-)
diff --git a/arch/x86_64/kernel/pci-calgary.c b/arch/x86_64/kernel/pci-calgary.c
index 5bd20b5..c472b14 100644
--- a/arch/x86_64/kernel/pci-calgary.c
+++ b/arch/x86_64/kernel/pci-calgary.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -341,17 +342,19 @@ static void iommu_free(struct iommu_table *tbl,
dma_addr_t dma_addr,
static void __calgary_unmap_sg(struct iommu_table *tbl,
struct scatterlist *sglist, int nelems, int direction)
{
- while (nelems--) {
+ struct scatterlist *s;
+ int i;
+
+ for_each_sg(sglist, s, nelems, i) {
unsigned int npages;
- dma_addr_t dma = sglist->dma_address;
- unsigned int dmalen = sglist->dma_length;
+ dma_addr_t dma = s->dma_address;
+ unsigned int dmalen = s->dma_length;
if (dmalen == 0)
break;
npages = num_dma_pages(dma, dmalen);
__iommu_free(tbl, dma, npages);
- sglist++;
}
}
@@ -374,10 +377,10 @@ void calgary_unmap_sg(struct device *dev, struct
scatterlist *sglist,
static int calgary_nontranslate_map_sg(struct device* dev,
struct scatterlist *sg, int nelems, int direction)
{
+ struct scatterlist *s;
int i;
- for (i = 0; i < nelems; i++ ) {
- struct scatterlist *s = [i];
+ for_each_sg(sg, s, nelems, i) {
BUG_ON(!s->page);
s->dma_address = virt_to_bus(page_address(s->page) +s->offset);
s->dma_length = s->length;
@@ -389,6 +392,7 @@ int calgary_map_sg(struct device *dev, struct scatterlist
*sg,
int nelems, int direction)
{
struct iommu_table *tbl = to_pci_dev(dev)->bus->self->sysdata;
+ struct scatterlist *s;
unsigned long flags;
unsigned long vaddr;
unsigned int npages;
@@ -400,8 +404,7 @@ int calgary_map_sg(struct device *dev, struct scatterlist
*sg,
spin_lock_irqsave(>it_lock, flags);
- for (i = 0; i < nelems; i++ ) {
- struct scatterlist *s = [i];
+ for_each_sg(sg, s, nelems, i) {
BUG_ON(!s->page);
vaddr = (unsigned long)page_address(s->page) + s->offset;
@@ -428,9 +431,9 @@ int calgary_map_sg(struct device *dev, struct scatterlist
*sg,
return nelems;
error:
__calgary_unmap_sg(tbl, sg, nelems, direction);
- for (i = 0; i < nelems; i++) {
- sg[i].dma_address = bad_dma_address;
- sg[i].dma_length = 0;
+ for_each_sg(sg, s, nelems, i) {
+ s->dma_address = bad_dma_address;
+ s->dma_length = 0;
}
spin_unlock_irqrestore(>it_lock, flags);
return 0;
diff --git a/arch/x86_64/kernel/pci-gart.c b/arch/x86_64/kernel/pci-gart.c
index ae091cd..b16384f 100644
--- a/arch/x86_64/kernel/pci-gart.c
+++ b/arch/x86_64/kernel/pci-gart.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -277,10 +278,10 @@ void gart_unmap_single(struct device *dev, dma_addr_t
dma_addr,
*/
void gart_unmap_sg(struct device *dev, struct scatterlist *sg, int nents, int
dir)
{
+ struct scatterlist *s;
int i;
- for (i = 0; i < nents; i++) {
- struct scatterlist *s = [i];
+ for_each_sg(sg, s, nents, i) {
if (!s->dma_length || !s->length)
break;
gart_unmap_single(dev, s->dma_address, s->dma_length, dir);
@@ -291,14 +292,14 @@ void gart_unmap_sg(struct device *dev, struct scatterlist
*sg, int nents, int di
static int dma_map_sg_nonforce(struct device *dev, struct scatterlist *sg,
int nents, int dir)
{
+ struct scatterlist *s;
int i;
#ifdef CONFIG_IOMMU_DEBUG
printk(KERN_DEBUG "dma_map_sg overflow\n");
#endif
- for (i = 0; i < nents; i++ ) {
- struct scatterlist *s = [i];
+ for_each_sg(sg, s, nents, i) {
unsigned long addr = page_to_phys(s->page) + s->offset;
if (nonforced_iommu(dev, addr, s->length)) {
addr = dma_map_area(dev, addr, s->length, dir);
@@ -318,23 +319,23 @@ static int dma_map_sg_nonforce(struct device *dev, struct
scatterlist *sg,
}
/* Map multiple scatterlist entries continuous into the first. */
-static int __dma_map_cont(struct scatterlist *sg, int start, int stopat,
+static int __dma_map_cont(struct
[PATCH 09/33] x86-64: update iommu/dma mapping functions to sg helpers
This prepares x86-64 for sg chaining support.
Additional improvements/fixups for pci-gart from
Benny Halevy [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Signed-off-by: Jens Axboe [EMAIL PROTECTED]
---
arch/x86_64/kernel/pci-calgary.c | 25 --
arch/x86_64/kernel/pci-gart.c| 63 -
arch/x86_64/kernel/pci-nommu.c |5 ++-
3 files changed, 51 insertions(+), 42 deletions(-)
diff --git a/arch/x86_64/kernel/pci-calgary.c b/arch/x86_64/kernel/pci-calgary.c
index 5bd20b5..c472b14 100644
--- a/arch/x86_64/kernel/pci-calgary.c
+++ b/arch/x86_64/kernel/pci-calgary.c
@@ -35,6 +35,7 @@
#include linux/pci_ids.h
#include linux/pci.h
#include linux/delay.h
+#include linux/scatterlist.h
#include asm/proto.h
#include asm/calgary.h
#include asm/tce.h
@@ -341,17 +342,19 @@ static void iommu_free(struct iommu_table *tbl,
dma_addr_t dma_addr,
static void __calgary_unmap_sg(struct iommu_table *tbl,
struct scatterlist *sglist, int nelems, int direction)
{
- while (nelems--) {
+ struct scatterlist *s;
+ int i;
+
+ for_each_sg(sglist, s, nelems, i) {
unsigned int npages;
- dma_addr_t dma = sglist-dma_address;
- unsigned int dmalen = sglist-dma_length;
+ dma_addr_t dma = s-dma_address;
+ unsigned int dmalen = s-dma_length;
if (dmalen == 0)
break;
npages = num_dma_pages(dma, dmalen);
__iommu_free(tbl, dma, npages);
- sglist++;
}
}
@@ -374,10 +377,10 @@ void calgary_unmap_sg(struct device *dev, struct
scatterlist *sglist,
static int calgary_nontranslate_map_sg(struct device* dev,
struct scatterlist *sg, int nelems, int direction)
{
+ struct scatterlist *s;
int i;
- for (i = 0; i nelems; i++ ) {
- struct scatterlist *s = sg[i];
+ for_each_sg(sg, s, nelems, i) {
BUG_ON(!s-page);
s-dma_address = virt_to_bus(page_address(s-page) +s-offset);
s-dma_length = s-length;
@@ -389,6 +392,7 @@ int calgary_map_sg(struct device *dev, struct scatterlist
*sg,
int nelems, int direction)
{
struct iommu_table *tbl = to_pci_dev(dev)-bus-self-sysdata;
+ struct scatterlist *s;
unsigned long flags;
unsigned long vaddr;
unsigned int npages;
@@ -400,8 +404,7 @@ int calgary_map_sg(struct device *dev, struct scatterlist
*sg,
spin_lock_irqsave(tbl-it_lock, flags);
- for (i = 0; i nelems; i++ ) {
- struct scatterlist *s = sg[i];
+ for_each_sg(sg, s, nelems, i) {
BUG_ON(!s-page);
vaddr = (unsigned long)page_address(s-page) + s-offset;
@@ -428,9 +431,9 @@ int calgary_map_sg(struct device *dev, struct scatterlist
*sg,
return nelems;
error:
__calgary_unmap_sg(tbl, sg, nelems, direction);
- for (i = 0; i nelems; i++) {
- sg[i].dma_address = bad_dma_address;
- sg[i].dma_length = 0;
+ for_each_sg(sg, s, nelems, i) {
+ s-dma_address = bad_dma_address;
+ s-dma_length = 0;
}
spin_unlock_irqrestore(tbl-it_lock, flags);
return 0;
diff --git a/arch/x86_64/kernel/pci-gart.c b/arch/x86_64/kernel/pci-gart.c
index ae091cd..b16384f 100644
--- a/arch/x86_64/kernel/pci-gart.c
+++ b/arch/x86_64/kernel/pci-gart.c
@@ -23,6 +23,7 @@
#include linux/interrupt.h
#include linux/bitops.h
#include linux/kdebug.h
+#include linux/scatterlist.h
#include asm/atomic.h
#include asm/io.h
#include asm/mtrr.h
@@ -277,10 +278,10 @@ void gart_unmap_single(struct device *dev, dma_addr_t
dma_addr,
*/
void gart_unmap_sg(struct device *dev, struct scatterlist *sg, int nents, int
dir)
{
+ struct scatterlist *s;
int i;
- for (i = 0; i nents; i++) {
- struct scatterlist *s = sg[i];
+ for_each_sg(sg, s, nents, i) {
if (!s-dma_length || !s-length)
break;
gart_unmap_single(dev, s-dma_address, s-dma_length, dir);
@@ -291,14 +292,14 @@ void gart_unmap_sg(struct device *dev, struct scatterlist
*sg, int nents, int di
static int dma_map_sg_nonforce(struct device *dev, struct scatterlist *sg,
int nents, int dir)
{
+ struct scatterlist *s;
int i;
#ifdef CONFIG_IOMMU_DEBUG
printk(KERN_DEBUG dma_map_sg overflow\n);
#endif
- for (i = 0; i nents; i++ ) {
- struct scatterlist *s = sg[i];
+ for_each_sg(sg, s, nents, i) {
unsigned long addr = page_to_phys(s-page) + s-offset;
if (nonforced_iommu(dev, addr, s-length)) {
addr = dma_map_area(dev, addr, s-length, dir);
@@ -318,23 +319,23 @@ static int dma_map_sg_nonforce(struct device *dev, struct
scatterlist *sg,
}
/* Map
Re: [PATCH 09/33] x86-64: update iommu/dma mapping functions to sg helpers
On Mon, 16 Jul 2007 11:47:23 +0200 Jens Axboe [EMAIL PROTECTED] wrote: This prepares x86-64 for sg chaining support. Additional improvements/fixups for pci-gart from Benny Halevy [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Signed-off-by: Jens Axboe [EMAIL PROTECTED] --- arch/x86_64/kernel/pci-calgary.c | 25 -- arch/x86_64/kernel/pci-gart.c| 63 - arch/x86_64/kernel/pci-nommu.c |5 ++- 3 files changed, 51 insertions(+), 42 deletions(-) This causes fairly extensive destruction of 2.6.23 changes which are pending in Andi's tree. I shall drop the block tree until a) Andi has merged the pending Calgary changes and b) the block tree has been fixed up to account for those (and other) changes. Really, this was the perfectly worst time possible to go tromping all over everyone else's trees. - 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/
Re: [PATCH 09/33] x86-64: update iommu/dma mapping functions to sg helpers
On Mon, Jul 16 2007, Andrew Morton wrote: On Mon, 16 Jul 2007 11:47:23 +0200 Jens Axboe [EMAIL PROTECTED] wrote: This prepares x86-64 for sg chaining support. Additional improvements/fixups for pci-gart from Benny Halevy [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Signed-off-by: Jens Axboe [EMAIL PROTECTED] --- arch/x86_64/kernel/pci-calgary.c | 25 -- arch/x86_64/kernel/pci-gart.c| 63 - arch/x86_64/kernel/pci-nommu.c |5 ++- 3 files changed, 51 insertions(+), 42 deletions(-) This causes fairly extensive destruction of 2.6.23 changes which are pending in Andi's tree. I shall drop the block tree until a) Andi has merged the pending Calgary changes and b) the block tree has been fixed up to account for those (and other) changes. Really, this was the perfectly worst time possible to go tromping all over everyone else's trees. Well, that's a bit hard for me to know, all I can do is push my stuff to for-akpm so that it gets -mm exposure. If I don't, then you are yelling at me as well :-) I'll keep rebasing sglist and the other branches I pull into for-akpm, so you can just re-enable the for-akpm pull when the a) is true. -- Jens Axboe - 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/
Re: [PATCH 09/33] x86-64: update iommu/dma mapping functions to sg helpers
On Mon, 16 Jul 2007 22:10:03 +0200 Jens Axboe [EMAIL PROTECTED] wrote: On Mon, Jul 16 2007, Andrew Morton wrote: On Mon, 16 Jul 2007 11:47:23 +0200 Jens Axboe [EMAIL PROTECTED] wrote: This prepares x86-64 for sg chaining support. Additional improvements/fixups for pci-gart from Benny Halevy [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Signed-off-by: Jens Axboe [EMAIL PROTECTED] --- arch/x86_64/kernel/pci-calgary.c | 25 -- arch/x86_64/kernel/pci-gart.c| 63 - arch/x86_64/kernel/pci-nommu.c |5 ++- 3 files changed, 51 insertions(+), 42 deletions(-) This causes fairly extensive destruction of 2.6.23 changes which are pending in Andi's tree. I shall drop the block tree until a) Andi has merged the pending Calgary changes and b) the block tree has been fixed up to account for those (and other) changes. Really, this was the perfectly worst time possible to go tromping all over everyone else's trees. Well, that's a bit hard for me to know, all I can do is push my stuff to for-akpm so that it gets -mm exposure. If I don't, then you are yelling at me as well :-) It is to be expected that there will be conflicts when making large-scale changes like this while there is 25MB of unmerged diff sitting out in 50 different trees. Doing it around the -rc1 time would be better. Even better would be not doing it at all: add the necessary stuff into the block core and then send the followup work to the relevant maintainers. ie: standard practice. I'll keep rebasing sglist and the other branches I pull into for-akpm, so you can just re-enable the for-akpm pull when the a) is true. Andi's tree is very out of date and is about to be damaged (to what extent I don't yet know) by a xen merge. I don't know if a) is going to happen. Things are more than usually messy this time around. - 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/
Re: [PATCH 09/33] x86-64: update iommu/dma mapping functions to sg helpers
On Mon, Jul 16, 2007 at 01:34:27PM -0700, Andrew Morton wrote: I'll keep rebasing sglist and the other branches I pull into for-akpm, so you can just re-enable the for-akpm pull when the a) is true. Andi's tree is very out of date and is about to be damaged (to what extent I don't yet know) by a xen merge. I don't know if a) is going to happen. The Xen and Calgary bits are mutually exclusive, so hopefully (a) will not be held up on account of the Xen merge (or for any other reason... CalIOC2 machines which are out there won't boot without it if CONFIG_CALGARY_IOMMU is enabled). Cheers, Muli - 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/
