> >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. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
