[PATCH 08/11] drm/ttm: introduce callback for ttm_tt populate & unpopulate

[Jerome Glisse]

On Mon, Nov 07, 2011 at 11:35:25AM -0600, Rob Clark wrote:
> On Thu, Nov 3, 2011 at 6:39 PM,  <j.glisse at gmail.com> wrote:
> > From: Jerome Glisse <jglisse at redhat.com>
> >
> > Move the page allocation and freeing to driver callback and
> > provide ttm code helper function for those.
> 
> btw, having page allocation/freeing in driver callback would solve one
> issue that I've been struggling with on ARM..  (well actually, two..
> but one that might not apply to some x86 drivers)
> 
> 1) for buffers mapped uncached/writecombine to userspace, I need a
> page that is removed from kernel linear map.  ARM requires that all
> virtual mappings of a page have the same cache attributes.  With GEM
> shmem backed buffers, I can't control page allocation.  The TTM DMA
> pool stuff looks also interesting in this regard, since I can avoid
> the need to do cache invalidate operations if I know the previous use
> of a page was not for a cached buffer.

yes it allows greater control to the device driver, i even though about
reusing same pages for transient buffer or similar things.

> 2) well, in some cases we need pages allocated in low 32bits..
> although this applies to some x86 drivers too, and there is a proposal
> of how to handle this issue.
> 
> Previously, since omapdrm is a UMA driver, I'd not looked too closely
> at TTM.. but maybe I need to revisit.  Is there any good example of a
> UMA driver using TTM?  (Or even some documentation.. although I'm
> happy with a good example.)

I think easiest example is vmwgfx.

> Just starting to look at the ttm code.. can you map back from 'struct
> ttm_tt' to the GEM object?  I'm wondering how the populate callback
> can know the cache attributes that the buffer is created with..
> (maybe a dumb question, I'm a newbie when it comes to the TTM code..)

Usualy driver do something like that :

struct mydriver_bo {
	struct ttm_buffer_object	tbo;
	struct drm_gem_object		gem_base;
	...
};

and so you use container_of to get back to your mydriver_bo struct
and then to your gem object.

That being said, ttm is usefull if you have thing like vram or stolen
ram + gart and the only way to get object in and out is to copy to/from
gart. For GPU where everythings is bound through a gart i think ttm is
overkill.

Note that there is no obligation to use the gem shmem allocator, you
can do your own gem stuff.

Cheers,
Jerome