Refactor stolen gem backend to use ttm. While this series is finished off to handle CI issues, I would appreciate a design review. In particulare any opinions on the following would be appreciated: 1. display fbc code using gem objects instead of drm_mm_node. The intent is rely on memory region as interface, instead of relying on knowledge of internals. This way ttm can be used in place of original stolen region without issue. 2. checking if a region has anything alloceted within a range. Instead of relying on internal access to the stolen region's drm_mm, add an interface to check if the range is busy that can work with any backend if implemetned. 3. Instead of region busy checking which is currently only used in testing, would we prefer a more general interface that could potentially be used for other infrastructure? e.g. for_each with callback over each resource/buffer within the range. Robert Beckett (7): drm/i915: instantiate ttm ranger manager for stolen memory drm/i915: add ability to create memory region object in place drm/i915: use gem objects to track stolen nodes drm/i915: stolen memory use ttm backend drm/ttm: add range busy check for range manager drm/i915: add range busy check for ttm region drm/i915: cleanup old stolen state drivers/gpu/drm/i915/display/intel_fbc.c | 76 +++-- drivers/gpu/drm/i915/gem/i915_gem_region.c | 55 ++++ drivers/gpu/drm/i915/gem/i915_gem_region.h | 6 + drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 351 +++------------------ drivers/gpu/drm/i915/gem/i915_gem_stolen.h | 16 +- drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 84 ++++- drivers/gpu/drm/i915/gem/i915_gem_ttm.h | 7 + drivers/gpu/drm/i915/gt/selftest_reset.c | 16 +- drivers/gpu/drm/i915/i915_drv.h | 5 - drivers/gpu/drm/i915/intel_memory_region.h | 6 + drivers/gpu/drm/i915/intel_region_ttm.c | 48 ++- drivers/gpu/drm/i915/intel_region_ttm.h | 3 + drivers/gpu/drm/ttm/ttm_range_manager.c | 21 ++ include/drm/ttm/ttm_range_manager.h | 3 + 14 files changed, 306 insertions(+), 391 deletions(-) -- 2.25.1
