[PATCH 2/2] drm/ttm: track kmap io_reserve(), only unreserve on unmap where needed
j.glisse at gmail.com
Tue Nov 9 06:33:44 PST 2010
On Tue, Nov 9, 2010 at 2:18 AM, Thomas Hellstrom <thomas at shipmail.org> wrote:
> On 11/09/2010 04:03 AM, Ben Skeggs wrote:
>> On Thu, 2010-11-04 at 19:34 +0100, Thomas Hellstrom wrote:
>>> I had something like the attached in mind, although it might be more
>>> beneficial to do the actual refcounting in drivers that needs it. Atomic
>>> incs and decs are expensive, but I'm not sure how expensive relative to
>>> function pointer calls.
>> Thanks for that :) It looks good to me, and appears to work as it
> I have a question, though. (CC'ing Jerome as well)
> Seems to me like something is missing from the mem_reserve interface. Let's
> say you have a programmable VRAM aperture and it's full, so you can't honor
> bo map request. You'd then want to traverse a list and call
> unmap_mapping_range() to kill user-space maps and free VRAM aperture space,
> but you can't really do that since you don't have access to the mapping
> range in question...?
Driver callback can callback into ttm to invalidate other bo mapping
and play with
aperture mapping (when i did the patch i think i did check locking was
ok but things
might have change since then).
The mecanism of io_mem_reserve & io_mem_free was thought for GPU where you
can change aperture mapping to vram (ie remap any chunk of vram into
thus with having the capacity of invalidating others bo mapping.
I will recheck the code to see if it can still do this from locking
point of view, of course
i never wrote any ttm helper function that would be needed to handle
this (we likely
want to avoid unmapping pinned buffer or especialy kmaped buffer.
More information about the dri-devel