Re: libata .sg_tablesize: why always dividing by 2 ?

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

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.