RE: [patch 2.6.13 0/6] swiotlb maintenance and x86_64 dma_sync_single_range_for_{cpu,device}

RE: [patch 2.6.13 0/6] swiotlb maintenance and x86_64 dma_sync_single_range_for_{cpu,device}

[Luck, Tony]

>Conduct some maintenance of the swiotlb code:
>
>	-- Move the code from arch/ia64/lib to lib

I agree that this code needs to move up out of arch/ia64, it is messy
that x86_64 needs to reach over and grab this from arch/ia64.

But is "lib" really the right place for it to move to?  Perhaps
a more logical place might be "drivers/pci/swiotlb/" since this
code is tightly coupled to pci?

-Tony

Re: [patch 2.6.13 0/6] swiotlb maintenance and x86_64 dma_sync_single_range_for_{cpu,device}

[Christoph Hellwig]

On Thu, Sep 22, 2005 at 01:37:46PM -0700, Luck, Tony wrote:
> >Conduct some maintenance of the swiotlb code:
> >
> >	-- Move the code from arch/ia64/lib to lib
> 
> I agree that this code needs to move up out of arch/ia64, it is messy
> that x86_64 needs to reach over and grab this from arch/ia64.
> 
> But is "lib" really the right place for it to move to?  Perhaps
> a more logical place might be "drivers/pci/swiotlb/" since this
> code is tightly coupled to pci?

It should just go away once the GFP_DMA32 code is merged.

Re: [patch 2.6.13 0/6] swiotlb maintenance and x86_64 dma_sync_single_range_for_{cpu,device}

[John W. Linville]

On Thu, Sep 22, 2005 at 09:41:55PM +0100, Christoph Hellwig wrote:
> On Thu, Sep 22, 2005 at 01:37:46PM -0700, Luck, Tony wrote:
> > >Conduct some maintenance of the swiotlb code:
> > >
> > >	-- Move the code from arch/ia64/lib to lib
> > 
> > I agree that this code needs to move up out of arch/ia64, it is messy
> > that x86_64 needs to reach over and grab this from arch/ia64.
> > 
> > But is "lib" really the right place for it to move to?  Perhaps
> > a more logical place might be "drivers/pci/swiotlb/" since this
> > code is tightly coupled to pci?
> 
> It should just go away once the GFP_DMA32 code is merged.

Is that the plan?  I suppose it makes sense.

So, move it to driver/pci/swiotlb.c?  Or just leave it where it is?

Either way, I'll redo the other patches to reflect the correct
location.

John
-- 
John W. Linville
linville@tuxdriver.com

Re: [patch 2.6.13 0/6] swiotlb maintenance and x86_64 dma_sync_single_range_for_{cpu,device}

[Muli Ben-Yehuda]

On Fri, Sep 23, 2005 at 02:22:35PM -0400, John W. Linville wrote:

> > It should just go away once the GFP_DMA32 code is merged.
> 
> Is that the plan?  I suppose it makes sense.

What about the odd devices that can do less than 32 bit DMA masks on
platforms without IOMMU?
 
> So, move it to driver/pci/swiotlb.c?  Or just leave it where it is?

drivers/pci/swiotlb.c makes sense. Xen has its own swiotlb.c these
days, moving it to drivers/pci/ should make it slightly easier to use
the generic one.

Cheers,
Muli
-- 
Muli Ben-Yehuda
http://www.mulix.org | http://mulix.livejournal.com/

Re: [patch 2.6.13 0/6] swiotlb maintenance and x86_64 dma_sync_single_range_for_{cpu,device}

[Andi Kleen]

On Friday 23 September 2005 20:27, Luck, Tony wrote:
> >> It should just go away once the GFP_DMA32 code is merged.
> >
> >Is that the plan?  I suppose it makes sense.
> >
> >So, move it to driver/pci/swiotlb.c?  Or just leave it where it is?
> >
> >Either way, I'll redo the other patches to reflect the correct
> >location.
>
> I don't have a good (or in fact any) understanding of the impact
> of GFP_DMA32 on ia64.  People tell me it will all be good, but I'd
> like to hear from someone running it.

It shouldn't change anything for IA64. GFP_DMA32 just becomes
an alias for your GFP_DMA.  On advantage is that drivers can
be now source level compatible between x86-64 and ia64 
for this (although they should be really using pci_alloc_consistent()
instead) 

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

swiotlb is still needed even with GFP_DMA32. Just move it.
2.6.15 won't have it also.

-Andi

Re: [patch 2.6.13 0/6] swiotlb maintenance and x86_64 dma_sync_single_range_for_{cpu,device}

[Grant Grundler]

On Fri, Sep 23, 2005 at 02:50:23PM -0400, John W. Linville wrote:
> On Fri, Sep 23, 2005 at 11:27:26AM -0700, Luck, Tony wrote:
> > >> It should just go away once the GFP_DMA32 code is merged.
> > >
> > >Is that the plan?  I suppose it makes sense.
> 
> > I don't have a good (or in fact any) understanding of the impact
> > of GFP_DMA32 on ia64.  People tell me it will all be good, but I'd
> > like to hear from someone running it.
>  
> All the patches I saw were for x86_64.  So, the impact on ia64 should
> be minimal... :-)

impact to arch/ia64 might be minimal. My understanding was
all the drivers that support 32-bit devices would need tweaks
to use GFP_DMA32 flag.  Is this still the plan?
	http://www.ussg.iu.edu/hypermail/linux/kernel/9901.3/0323.html

Most of what I've read in Andi's patch otherwise makes sense:
	http://lwn.net/Articles/152337/

But I didn't see Andi suggest that swiotlb should go completely away.

thanks,
grant

Re: [patch 2.6.13 0/6] swiotlb maintenance and x86_64 dma_sync_single_range_for_{cpu,device}

[John W. Linville]

On Fri, Sep 23, 2005 at 11:27:26AM -0700, Luck, Tony wrote:
> >> It should just go away once the GFP_DMA32 code is merged.
> >
> >Is that the plan?  I suppose it makes sense.

> I don't have a good (or in fact any) understanding of the impact
> of GFP_DMA32 on ia64.  People tell me it will all be good, but I'd
> like to hear from someone running it.
 
All the patches I saw were for x86_64.  So, the impact on ia64 should
be minimal... :-)

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

The xen guys have an swiotlb implementation, although theres differs
somewhat.  Perhaps if we moved it out from under ia64, the two could
be consolidated?

John
-- 
John W. Linville
linville@tuxdriver.com

RE: [patch 2.6.13 0/6] swiotlb maintenance and x86_64 dma_sync_single_range_for_{cpu,device}

[Luck, Tony]

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

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

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

-Tony

[patch 2.6.13 0/6] swiotlb maintenance and x86_64 dma_sync_single_range_for_{cpu,device}

[John W. Linville]

Conduct some maintenance of the swiotlb code:

	-- Move the code from arch/ia64/lib to lib

	-- Cleanup some cruft (code duplication)

	-- Add support for syncing sub-ranges of mappings

	-- Add support for syncing DMA_BIDIRECTIONAL mappings

	-- Comment fixup & change record

Also, tack-on an x86_64 implementation of dma_sync_single_range_for_cpu
and dma_sync_single_range_for _device.  This makes use of the new
swiotlb sync sub-range support.

Patches to follow...