On Dec 12, 2011, at 10:27 PM, Benjamin Herrenschmidt wrote:
On Mon, 2011-12-12 at 21:55 -0600, Becky Bruce wrote:
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
On Tue, 2011-12-13 at 20:53 -0600, Becky Bruce wrote:
The non-coherent specialness is in the dma sync stuff and no, I
don't think the iotlb stuff deals with that properly.
Do you not have a problem with 1)? If not then I think we can look at
switching over; 2) was more of a secondary thing.
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 =
On Mon, 2011-12-12 at 21:55 -0600, Becky Bruce wrote:
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,
We assumed before that alloc_coherent free_coherent ops would always
be direct because of 32-bit systems and how we utilize highmem lowmem.
However, on 64-bit systems we typically treat all memory as lowmem so
the same assumptions are not valid. We need to utilze the swiotlb
versions of
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 =
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
