Re: [PATCH] cleanup: Add 'struct dev' in the TTM layer to be passedin for DMA API calls.
From: Thomas Hellstrom
Date: Wed Mar 23 2011 - 04:14:04 EST
On 03/22/2011 03:31 PM, Konrad Rzeszutek Wilk wrote:
On Tue, Mar 08, 2011 at 09:52:54PM +0100, Thomas Hellstrom wrote:
Hi, Konrad,Soo.. it seems it is on PowerPC, which I sadly didn't check for, does require
Is passing a struct device to the DMA api really *strictly* necessary?
I'd like to avoid that at all cost, since we don't want pages thatI was thinking about this a bit after I found that the PowerPC requires
are backing buffer objects
(coherent pages) to be associated with a specific device.
The reason for this is that we probably soon will want to move ttm
buffer objects between devices, and that should ideally be a simple
operation: If the memory type the buffer object currently resides in
is not shared between two devices, then move it out to system memory
and change its struct bo_device pointer.
the 'struct dev'. But I got a question first, what do you with pages
that were allocated to a device that can do 64-bit DMA and then
move it to a device than can 32-bit DMA? Obviously the 32-bit card would
set the TTM_PAGE_FLAG_DMA32 flag, but the 64-bit would not. What is the
process then? Allocate a new page from the 32-bit device and then copy over the
page from the 64-bit TTM and put the 64-bit TTM page?
Yes, in certain situations we need to copy, and if it's necessary in
some cases to use coherent memory with a struct device assoicated with
it, I agree it may be reasonable to do a copy in that case as well. I'm
against, however, to make that the default case when running on bare metal.
However, I've looked a bit deeper into all this, and it looks like we
already have other problems that need to be addressed, and that exists
with the code already in git:
Consider a situation where you allocate a cached DMA32 page from the ttm
page allocator. You'll end up with a coherent page. Then you make it
uncached and finally you return it to the ttm page allocator. Since it's
uncached, it will not be freed by the dma api, but kept in the uncached
pool, and later the incorrect page free function will be called.
I think we might need to take a few steps back and rethink this whole idea:
1) How does this work in the AGP case? Let's say you allocate
write-combined DMA32 pages from the ttm page pool (in this case you
won't get coherent memory) and then use them in an AGP gart? Why is it
that we don't need coherent pages then in the Xen case?
2) http://www.mjmwired.net/kernel/Documentation/DMA-API.txt, line 33
makes me scared.
We should identify what platforms may have problems with this.
3) When hacking on the unichrome DMA engine it wasn't that hard to use
the synchronization functions of the DMA api correctly:
When binding a TTM, the backend calls dma_map_page() on pages, When
unbinding, the backend calls dma_unmap_page(), If we need cpu access
when bound, we need to call dma_sync_single_for_[cpu|device]. If this is
done, it will be harder to implement user-space sub-allocation, but
possible. There will be a performance loss on some platforms, though.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/