On Tue, Nov 9, 2010 at 2:18 AM, Thomas Hellstrom <thomas@xxxxxxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
