This situation could occur on native/baremetal. When you say 'defaultI was thinking about this a bit after I found that the PowerPC requiresYes, in certain situations we need to copy, and if it's necessary in
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?
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.
case' you mean for every type of page without consulting whether it
had the TTM_PAGE_FLAG_DMA32?
However, I've looked a bit deeper into all this, and it looks likeLet me look in details in the code, but I thought it would check the
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.
TTM_PAGE_FLAG_DMA32 and direct the page to the correct pool?
We could piggyback on the idea of the struct I had and have these
values:
struct ttm_page {
struct page *page;
dma_addr_t *bus_addr;
struct *ttm_pool *origin;
}
And the origin would point to the correct pool so that on de-allocate
it would divert it to the original one. Naturally there would
be some thinking to be done on the de-alloc path so that
the *origin isn't pointing to something htat has already been free-d.
I think we might need to take a few steps back and rethink this whole idea:Hehe.. So I had posted a set of patches to carry the 'dma_addr_t' through
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?
the AGP API and then to its backends to program that. And also the frontends
(so DRM, TTM) Here is the
patchset I posted some time ago:
http://linux.derkeiler.com/Mailing-Lists/Kernel/2010-12/msg02382.html
and the discussion:
http://linux.derkeiler.com/Mailing-Lists/Kernel/2010-12/msg02411.html
Dave recommended I skip AGP and just concentrate on PCIe since not to many
folks use AGP anymore. Thought I realized that server boards use PCI
cards (ATI ES1000), which do utilize the AGP API. So there is breakage there
and I have a set of patches for this that I was in process of rebasing
on 2.6.39-rcX.
2) http://www.mjmwired.net/kernel/Documentation/DMA-API.txt, line 33Right.. I think nobody much thought about this in context of TTM since
makes me scared.
We should identify what platforms may have problems with this.
that was only used on X86. I can take a look at the DMA API's of the
other two major platforms: IA64 and PPC and see what lurks there.
3) When hacking on the unichrome DMA engine it wasn't that hard toYup. That was my other suggestion about this. But I had no idea
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.
where to sprinkle those 'dma_sync_single_[*]' calls, as they would
have been done in the drivers. Probably on its DMA paths, right before
telling the GPU to process the CP, and when receiving an interrupt
when the CP has been completed.