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

>> 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
-
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/

---

• Follow-Ups:
  • [patch 2.6.14-rc2 0/5] swiotlb maintenance and x86_64 dma_sync_single_range_for_{cpu,device}
    • From: "John W. Linville" <[email protected]>
  • Re: [patch 2.6.13 0/6] swiotlb maintenance and x86_64 dma_sync_single_range_for_{cpu,device}
    • From: Andi Kleen <[email protected]>
  • Re: [patch 2.6.13 0/6] swiotlb maintenance and x86_64 dma_sync_single_range_for_{cpu,device}
    • From: "John W. Linville" <[email protected]>

• Prev by Date: Re: [patch] sys_epoll_wait() timeout saga ...
• Next by Date: Re: Trapping Block I/O
• Previous by thread: Re: [patch 2.6.13 0/6] swiotlb maintenance and x86_64 dma_sync_single_range_for_{cpu,device}
• Next by thread: Re: [patch 2.6.13 0/6] swiotlb maintenance and x86_64 dma_sync_single_range_for_{cpu,device}
• Index(es):
  • Date
  • Thread

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]