For that there are couple of architectural issues I am not sure how to solve.
There has to be some form of TTM<->[Radeon|Nouveau] lookup mechanism to say: "here is a 'struct page *', give me the bus address". Currently this is solved by keeping an array of DMA addresses along with the list of pages. And passing the list and DMA address up the stack (and down) from TTM up to the driver (when ttm->be->func->populate is called and they are handed off) does it. It does not break any API layering .. and the internal TTM pool (non-DMA) can just ignore the dma_address altogether (see patch above).
I actually had something more simple in mind, but when tinking a bit deeper into it, it seems more complicated than I initially thought.
Namely that when we allocate pages from the ttm_backend, we actually populated it at the same time. be::populate would then not take a page array as an argument, and would actually be a no-op on many drivers.
The programming of the gfx's MMU.. would be done via a new API call? I think this needs a bit of whiteboarding for me to be sure I understand you.
This makes us move towards struct ttm_tt consisting almost only of its backend, so that whole API should perhaps be looked at with new eyes.
So anyway, I'm fine with high level things as they are now, and the
Great!
dma_addr issue can be looked at at a later time. If we could get a couple of extra eyes to review the code for style etc. would be
Anybody in particular you can recommend that I can pester^H^H^H^H politely ask :-)
great, because I have very little time the next couple of weeks.
<nods> Understood.