[PATCH 2/2] drm/ttm: track kmap io_reserve(), only unreserve on unmap where needed

[Jerome Glisse]

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:
>>
>>>
>>> Ben,
>>>
>>> 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.
>>>
>>
>> Thomas,
>>
>> Thanks for that :)  It looks good to me, and appears to work as it
>> should.
>>
>> Ben.
>>
>
> Great.
>
> 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...?
>
> /Thomas
>
>

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
the aperture),
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.

Cheers,
Jerome