On Mon, Sep 26, 2011 at 01:18:40PM -0500, Rob Clark wrote:
> On Thu, Sep 15, 2011 at 5:47 PM, Rob Clark <rob.clark@xxxxxxxxxx> wrote:
> > +/**
> > + * drm_gem_get_pages - helper to allocate backing pages for a GEM object
> > + * @obj: obj in question
> > + * @gfpmask: gfp mask of requested pages
> > + */
> > +struct page ** drm_gem_get_pages(struct drm_gem_object *obj, gfp_t gfpmask)
> > +{
>
>
> Hmm, in working through tiled buffer support over the weekend, I think
> I've hit a case where I want to decouple the physical size (in terms
> of pages) from virtual size.. which means I don't want to rely on the
> same obj->size value for mmap offset creation as for determining # of
> pages to allocate.
>
> Since the patch for drm_gem_{get,put}_pages() doesn't seem to be on
> drm-core-next yet, I think the more straightforward thing to do is add
> a size (or numpages) arg to the get/put_pages functions resubmit this
> patch..
I think making obj->size not be the size of the backing storage is the
wrong thing. In i915 we have a similar issue with tiled regions on gen2/3:
The minimal sizes for these are pretty large, so objects are smaller than
a the tiled region. So backing storage and maps are both obj->size large,
but the area the object occupies in the gtt may be much large. To put some
packing storage behind the not-used region (which sounds like what you're
trying to do here) we simply use one global dummy page. Userspace should
never use this, so that's fine.
Or is this a case of insane arm hw, and you can't actually put the same
physical page at different gtt locations?
-Daniel
--
Daniel Vetter
Mail: daniel@xxxxxxxx
Mobile: +41 (0)79 365 57 48
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
