[PATCH] powerpc: Fix swiotlb ops for ppc64

[Becky Bruce]

On Dec 7, 2011, at 11:46 PM, Kumar Gala wrote:

> 
> On Dec 7, 2011, at 9:23 PM, Benjamin Herrenschmidt wrote:
> 
>> On Wed, 2011-12-07 at 11:19 -0600, Kumar Gala wrote:
>> 
>>> struct dma_map_ops swiotlb_dma_ops = {
>>> +#ifdef CONFIG_PPC64
>>> +	.alloc_coherent = swiotlb_alloc_coherent,
>>> +	.free_coherent = swiotlb_free_coherent,
>>> +#else
>>> 	.alloc_coherent = dma_direct_alloc_coherent,
>>> 	.free_coherent = dma_direct_free_coherent,
>>> +#endif
>>> 	.map_sg = swiotlb_map_sg_attrs,
>>> 	.unmap_sg = swiotlb_unmap_sg_attrs,
>>> 	.dma_supported = swiotlb_dma_supported,
>> 
>> Do we really need the ifdef ? What happens if we use
>> swiotlb_alloc_coherent() on ppc32 ? Won't it allocate lowmem, realize
>> that it doesn't need bouncing and be happy ?
>> 
>> Cheers,
>> Ben.
> 
> Becky any comment?
> 
> I know its been a while, but wondering if you had any reason to not do what Ben's suggesting ?

Well, as you say, it's been a while, and but I think:

1) dma_direct_alloc_coherent strips GFP_HIGHMEM out of the flags field when calling the actual allocator and the iotlb version does not.  I don't know how much this matters - I did a quick grep and I don't see any users that specify that, but somebody went through the trouble of putting it in there in the first place and without knowing why I wasn't willing to get rid of it.  Now, since my patch it looks like someone added a VM_BUG_ON into __get_free_pages() if GFP_HIGHMEM so this would get caught.  However, I don't know if we really want to throw a bug there.

2)  The iotlb code doesn't deal with the !coherent parts like 8xx.  We can work around that by setting up the dma_ops differently for that case instead.

-Becky