Messages in this thread | | | Date | Mon, 24 Oct 2011 14:18:06 -0400 | From | Konrad Rzeszutek Wilk <> | Subject | Re: [PATCH 06/11] ttm/driver: Expand ttm_backend_func to include two overrides for TTM page pool. |
| |
> >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.
| |