Benjamin Herrenschmidt wrote:
OK. It seems like mmap locks are needed even for unmap_mapping_range().I don't think so. We are not doing vram yet in the TTM code, but I think a general "eviction" would consist of Unfortunately, the DRM currently doesn't have a unique inode address space. File handles (offsets) are sort of arbitrary hash tokens, so unmap_mapping_range() cannot be used for drm maps (ttms). Instead I'd like to have the zap_page_range() function exported. (That means, however, keeping track on all vmas in the driver). I think it would be possible, however, to have a unique inode address space also for DRM. That would mean having a separate space manager for that space, and we'll always be restricted to 32-bits (size of drm_handle_t) minus the area reserved for IO mappings. That's actually a quite limiting restriction. We should probably use a 64-bit mapping handle for buffers with new map and unmap functions, keeping compatibility with the old code by having the old drm maps using the lower 32 bits. That should be quite easily implemented. /Thomas Ben. |
------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
-- _______________________________________________ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
