On Mon, May 09, 2022 at 03:09:40PM +0200, Christian König wrote: > Hi everyone, > > re-sending this because Daniel was requesting a background why this is > useful. Thanks a lot for typing this up. To make sure this isn't lost, could you add a patch to at least add this as a comment to ttm_buffer_object.resource, ideally rolling out the kerneldoc scaffolding for that file while at it and making it kerneldoc? I think documenting that kind of why&how for key links like ttm_bo->ttm_resource is really important. > When TTM creates a buffer this object initially should not have any > backing store and there no resource object associated with it. The same > can happen when a driver requests that the backing store of an object is > destroyed without allocating a new one. > > This is really useful during initial buffer creation as well as temporary > buffers and page tables which content doesn't need to be preserved when > they are evicted. > > Currently TTM allocates dummy system resources for that because drivers > couldn't handle a NULL pointer there. Audit the drivers and then clean > up TTM to stop making those dummy allocations. Also I guess this is good prep work for going the other direction, i.e. allowing more than one ttm_resource per ttm_bo? Or is that all mostly orthogonal issues that bo:resource 1:N for N=0 has vs 1:N for N > 1? > Please review and comment, I'll ... try. But maybe call in some favours from other i915 ttm folks because I'm just really bad at doing review timeline these days :-/ -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
