[PATCH] [POWERPC] Add struct iommu_table argument to iommu_map_sg()

[Mark Nelson]

Olof Johansson wrote:
> On Tue, Apr 29, 2008 at 03:17:45PM +1000, Mark Nelson wrote:
>> Make iommu_map_sg take a struct iommu_table. It did so before commit
>> 740c3ce66700640a6e6136ff679b067e92125794 (iommu sg merging: ppc: make
>> iommu respect the segment size limits).
>>
>> This stops the function looking in the archdata.dma_data for the iommu
>> table because in the future it will be called with a device that has
>> no table there.
> 
> The logical thing would be to add the archdata.dma_data to said device
> instead, no? Without seeing the rest of the code that makes use of it
> it's hard to tell anyway, so please post that.

I'll post the follow on series of patches as an RFC to give you a better
understanding of what I'm trying to do; but basically I'm building on
the new dma_*map*_attrs() interfaces that Andrew Morton sent to Linus
last night and implementing them for powerpc (in particular the Cell
platform). To cut a longish story short, the fixed linear mapping for
the Cell's IOMMU can be set to either be weakly or strongly ordered,
and so a device that has been identified as being able to use the
fixed mapping can later request a mapping that cannot be satisfied using
the fixed mapping (eg: it may request a weakly ordered mapping when
the fixed mapping is strongly ordered, or vice versa). Devices that
use the fixed mapping use the dma_direct_ops with their dma_data being
the necessary offset, but for the case above they have to use the
iommu_map*() functions that the dma_iommu_ops use. So that's how we end
up calling iommu_map_sg() with a device that doesn't have the table
in the dma_data (and already has something useful in dma_data).

I'll try to get the follow on series of patches cleaned up today and
send them out asap, so if my ramblings above turned out to be too
obscure the code will hopefully clear things up.

Thanks!

Mark.

> 
>> This also has the nice side effect of making iommu_map_sg() match the
>> other map functions.
> 
> Consistency is good, but I wonder if the opposite wouldn't be the better
> way to go here: always just pass down just the dev pointer instead. The
> table can be reached from it.
> 
> 
> -Olof
>