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
_______________________________________________
Linuxppc-dev mailing list
[email protected]
https://lists.ozlabs.org/listinfo/linuxppc-dev
