Quoting Michal Wajdeczko (2019-11-21 17:58:50) > Today VGT implements GGTT ballooning on its own, using some private > static structure to hold info about reserved GGTT nodes and then > manually update vm.reserved size owned by i915_ggtt. > > As i915_ggtt already manages some custom reserved nodes (like uc_fw) > move VGT ballooning support to i915_ggtt and make it more generic > for possible future reuse in other scenarios. > > As a bonus we can drop another place in driver that uses static data. > > Signed-off-by: Michal Wajdeczko <michal.wajdeczko@xxxxxxxxx> > Cc: Xiong Zhang <xiong.y.zhang@xxxxxxxxx> > Cc: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > Cc: Jani Nikula <jani.nikula@xxxxxxxxx> > --- > drivers/gpu/drm/i915/i915_gem_gtt.c | 47 +++++++++++++++++++ > drivers/gpu/drm/i915/i915_gem_gtt.h | 18 ++++++++ > drivers/gpu/drm/i915/i915_vgpu.c | 72 ++++++----------------------- > 3 files changed, 78 insertions(+), 59 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c > index 6239a9adbf14..d8b2084dab7e 100644 > --- a/drivers/gpu/drm/i915/i915_gem_gtt.c > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c > @@ -3827,6 +3827,53 @@ int i915_gem_gtt_insert(struct i915_address_space *vm, > start, end, DRM_MM_INSERT_EVICT); > } > > +int i915_ggtt_balloon_space(struct i915_ggtt *ggtt, > + enum i915_ggtt_balloon_id id, Do we want to use a fixed number of slots? So what exactly is wrong with the clients reserving nodes themselves? I'm not seeing why exactly we want to move to a much more centralised system and argue over ownership of i915_ggtt_balloon_id. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
