I don't know why it was done that way, but I wrote the TTM DMA code to be optimized for that (and it has the code to reverse direction - b/c the testcases I used initially had the a,b,c,d,e,f order when doing get_pages and put_pages) - but I can alter the code to do it in the forward fashion instead of the reverse fashion.. Better yet, it removes around 70 lines of code from the TTM DMA.
Order in which we put them back on the list can be easily change, either by use of add_tail or by iterating array from end to begining. i am not sure how much this can impact things.
Neither am I. I can run some perf numbers when playing tuxracer and see if there is a disadvantage/advantage.
Anyhow, it might be noting that in the commit description and perhaps make a bug-fix for the put_pages being called in the error path instead of ttm_put_pages as a seperate patch as you suggested.
[PATCH 6/6] drm/ttm: merge ttm_backend and ttm_tt
That is going to be a bit tricky. You are using the pci_map_page, which should not be used if the pages have been allocated via the pci_alloc_coherent (they are already mapped). Perhaps a simple check such as:
if !(ttm->be && ttm->be->func && ttm->be->func->get_pages) { ttm->dma_address[i] = pci_map_page(dev->pdev, ...) }
Your dma change are not suppose to be on top of that, idea is to add yet another callbacks populate+free_page which will do either pci map page or just use your code (ie use dma alloc and store dma addr into the array). So there is a missing piece here before adding your dma code. I just wanted to keep ttm_tt & ttm_backend merge as simple as possible without major change. Adding the populate + get_page callback sounded like good candidate for another patch.
<nods>
What base should I be looking at? Is this the base that Dave has for 3.2?
Should apply on top of linus master kernel as of yesterday.
Oh.. very very *very* fresh.