On Mon, 2010-10-11 at 00:09 +0900, FUJITA Tomonori wrote: > On Sat, 09 Oct 2010 10:44:53 +1100 > Benjamin Herrenschmidt <b...@kernel.crashing.org> wrote: > > > On Fri, 2010-10-08 at 10:33 -0700, Nishanth Aravamudan wrote: > > > Also allow the coherent ops to be iommu if only the coherent mask is too > > > small, mostly for driver that do not set set the coherent mask but also > > > don't use the coherent api. > > > > You are doing the transition at map_sg time which is a hot path, I don't > > like that. Also you add all those "choose" variants of the dma ops... > > not very nice at all. > > Agreed, looks hacky. > > > > You may want to look at the patches I posted to the list a while back > > for doing direct DMA on Bimini: > > > > [PATCH 1/2] powerpc/dma: Add optional platform override of dma_set_mask() > > Would it be cleaner if each ppc dma_map_ops has the own set_dma_mask > and dma_set_mask simply calls dma_map_ops->set_dma_mask?
I'm not sure I parse what you wrote above :-) I did try with various methods back then, and what ended up sucking the less was basically to hookup dma_set_mask() at the arch level. In fact, it makes sense to the extent that the arch is the one that knows that there are multiple regions configured potentially with different capabilities. You can still do the switch within the dma_ops->set_dma_mask if you want I suppose, especially if you end up hitting different attribute regions within a single bus or such but from my experience, it gets really hacky with multiple ops structures etc... > > > [PATCH 2/2] powerpc/dart_iommu: Support for 64-bit iommu bypass window on > > PCIe > Cheers, Ben. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev