Mark Lord wrote:
Benjamin Herrenschmidt wrote:
On Tue, 2008-02-26 at 00:43 -0500, Mark Lord wrote:
I suppose so. I don't remember all of the details, but iirc, it has to
do with crossing 64K boundaries. Some controllers can't handle it.
It's not only the _size_ of the segments, it's their alignment.
The iommu will not keep alignement beyond the page size (and even
then... on powerpc with a 64k base page size, you may still end up with
a 4k aligned result, but let's not go there now).
..
That's just not possible, unless the IOMMU *splits* segments.
And the IOMMU experts here say that it never does that.
It is totally possible, and I know as wrote part of the powerpc iommu
code :-)
The iommu code makes no guarantee vs. preserving the alignment of a
segment, at least not below PAGE_SIZE.
Thus if you pass to dma_map_sg() a 64K aligned 64K segment, you may well
get back a 4K aligned 64K segment.
Enforcing natural alignment in the iommu code only happens for
dma_alloc_coherent (it uses order-N allocations anyway), it doesn't
happen for map_sg. If we were to do that, we would make it very likely
for iommu allocations to fail on machine with small DMA windows.
Ben.
..
That's interesting. Can you point us to the exact file::lines where
this happens? It would be good to ensure that this gets fixed.
I'm copying Fujita Tomonori on this thread now -- he's the dude who's
trying to sort out the IOMMU mess.
..
Mmm.. looks like ppc is already fixed in mainline,
commit 740c3ce66700640a6e6136ff679b067e92125794
Ben?
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
