On Tue, Sep 09, 2008 at 09:39:20AM -0500, Becky Bruce wrote: > .... because you asked me to have just map/unmap_page in your review > of an earlier rev of this patch series in May? :) I don't actually > expect you to remember this, because it was a long time ago, but > here's the relevant chunk of the conversation: > > On May 23, 2008, at 4:51 AM, Christoph Hellwig wrote: > > >On Wed, Apr 30, 2008 at 06:36:43PM -0500, Becky Bruce wrote: > >>In addition, the dma_map/unmap_page functions are added to dma_ops on > >>HIGHMEM-enabled configs because we can't just fall back on map/ > >>unmap_single > >>when HIGHMEM is enabled. Adding these to dma_ops makes it cleaner to > >>substitute different functionality once we have iommu/swiotlb > >>support. > > > >Maybe I'm missing something but we should only have the page ones. > >virt_to_page is cheap and we'll most likely need the phys address > >which > >we get from the page anyway. > > > So I did that for the dma_direct_* ops, but discovered that doing it > for the iommu case (which I can't test and don't fully understand) > would be a bit more complicated. The above code (in conjunction with > the same code for map_page) allows you to have map/unmap_page, map/ > unmap_single, or both. I'm happy to change it again, though. We > could just do the above in map_page/unmap_page, calling map/ > unmap_single if there is no map/unmap_page, and provide both a > dma_direct_map/unmap_single and a dma_direct_map/unmap_page for the > dma_direct* ops.
Yeah, the statement this time should be why do you keep _single :) It don't really mind which one we keep, but having both and both optional seems rather odd. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
