Quoting Michal Wajdeczko (2019-06-14 18:18:54) > On Fri, 14 Jun 2019 17:17:01 +0200, Tvrtko Ursulin > <tvrtko.ursulin@xxxxxxxxxxxxxxx> wrote: > > > From: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx> > > > > More removal of implicit dev_priv from using old mmio accessors. > > > > Furthermore these calls really operate on ggtt so it logically makes > > sense > > if they take it as parameter. > > Hmm, I'm not sure that we going in right direction here, as these > functions mostly operate on bl_info that today is separate to ggtt. That was my first thought too, except they are operating inside of ggtt init/fini. > Maybe better option would be to move pure ggtt related functions > vgt_balloon_space/vgt_deballoon_space to i915_gem_ggtt.c|h (after > rename) and allow vgpu functions to keep i915 as parameter ? Presumably, vgpu would migrate to taking its own object as well. Still undecided how best to handle ggtt init plugins. My ideal would be that vgpu init was dynamic and be tuned to work with an existing ggtt, and never rely on static partitioning. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
