On Mon, Nov 07, 2011 at 11:35:25AM -0600, Rob Clark wrote:
> On Thu, Nov 3, 2011 at 6:39 PM, <j.glisse@xxxxxxxxx> wrote:
> > From: Jerome Glisse <jglisse@xxxxxxxxxx>
> >
> > 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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
