Re: [RFC 01/31] drm/i915: Convert intel_vgt_(de)balloon to uncore

[Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>]

On 14/06/2019 18:43, Chris Wilson wrote:
> Quoting Michal Wajdeczko (2019-06-14 18:18:54)
>> On Fri, 14 Jun 2019 17:17:01 +0200, Tvrtko Ursulin
>> <tvrtko.ursulin@linux.intel.com> wrote:
>>
>>> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>>
>>> 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.

And it does actually modify ggtt: intel_vgt_balloon -> vgt_balloon_space 
-> i915_gem_gtt_reserve.

So to me it sounded passable to make them take ggtt as input parameter. 
It is not detrimental if they (the functions) one day decide to wrap 
both bl_info and ggtt into a new object.

Sounds passable or objection is hard?

Regards,

Tvrtko

>> 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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx